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ABSTRACT 


Currently,  all  Missile  Defense  Ageney  (MDA)  instrumentation  radars  are  land-based  at 
Reagan  Test  Site  (RTS)  in  the  Marshall  Islands  and  the  Pacific  Missile  Range  Facility 
(PMRF)  on  the  Hawaiian  island  of  Kauai.  The  dependency  on  land-based  radars  produces 
significant  gaps  in  radar  coverage  of  planned  ballistic  missile  defense  system  (HMDS) 
tests.  The  S.S.  Beaver  State  is  a  former  cargo  ship  that  was  converted  to  a  crane  ship. 
The  purpose  of  a  crane  ship  is  to  unload/load  other  ships  at  ports  with  inadequate 
facilities.  When  the  Beaver  State  was  converted  to  a  crane  ship,  three  large  cranes  were 
installed.  The  size  of  the  ship  and  generators  make  the  Beaver  State  suitable  to  host  the 
first  X-Band  Test  Radar  (XTR-1)  and  the  second  Transportable  Telemetry  System  (TTS- 
2).  There  are  five  major  efforts  in  the  conversion  process:  1)  Ship  reactivation;  2) 
Modification  of  the  ship  to  host  the  primary  sensors,  the  adjunct  systems,  and  the 
respective  operators;  3)  Installation  and  integration  of  the  primary  sensors  and  adjunct 
systems;  4)  Development,  installation,  and  certification  of  the  communications  system; 
and  5)  Coast  Guard  certification.  This  thesis  will  review  the  history  of  the  modification 
design  and  communications  system  development  aspects  of  this  conversion  process, 
review  the  Department  of  Defense  Architectural  Framework  (DoDAF),  assess  the 
applicability  of  DoDAF  to  the  Beaver  State  conversion  process,  and  suggest  opportunities 
for  improvement  of  similar  MDA  test  asset  development  programs. 
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EXECUTIVE  SUMMARY 


The  conclusion  of  this  thesis  is  the  application  of  the  Department  of  Defense  Architecture 
Framework  (DoDAF)  to  the  design  effort  to  convert  a  crane  ship,  Beaver  State,  to  a  range 
instrumentation  ship  would  not  have  been  very  useful.  The  effort  to  convert  Beaver 
State,  to  be  re-named  Pacific  Tracker,  has  five  major  efforts:  1)  Ship  reactivation,  Beaver 
State  had  been  mothballed  in  the  Department  of  Transportation,  Maritime 
Administration’s  (MARAD)  inactive  reserve  fleet;  2)  Modification  of  Beaver  State  to 
host  the  Missile  Defense  Agency’s  X-Band  Test  Radar  (XTR-1),  one  of  its  Transportable 
Telemetry  Systems  (TTS),  adjunct  systems,  and  respective  operators;  3)  Installation  and 
integration  of  XTR-1,  TTS,  and  adjunct  systems;  4)  Development,  ,  installation,  and 
certification  of  the  communications  system;  5)  Coast  Guard  certification.  The  major 
engineering  efforts  in  the  conversion  process  that  were  considered  in  this  thesis  are:  1) 
The  design  of  the  modification  for  the  ship  to  host  the  radar,  telemetry,  adjunct  systems, 
and  the  respective  operators;  and  2)  the  design  of  the  communications  system.  DoDAF 
with  its  emphasis  on  interoperability  would  not  have  significantly  impacted  the  major 
ship  modifications  such  as:  modifications  to  house  system  operators;  TTS  placement,  or 
electrical  system  modifications.  Application  of  DoDAF  to  the  communications  system 
development  would  also  not  have  a  significant  impact  largely  due  to  the  evolutionary 
aspect  of  the  communication  system  and  the  maturity  of  the  established  communication 
architecture. 

This  thesis  reviews  other  ships.  Pacific  Collector,  Worthy,  Observation  Island, 
and  SBX  which  MDA  has  used  for  BMDS  testing.  Then  the  Beaver  State  conversion 
project  history  and  DoDAF  are  reviewed.  Next,  sample  DoDAF  products  that  could  have 
been  produced  for  the  Beaver  State  conversion  are  developed.  The  assessment  is  made 
that  the  application  of  DoDAF  would  not  have  been  very  useful  to  the  project  and 
DoDAF ’s  utility  for  future  MDA  test  asset  developments  would  likely  be  similar. 
However,  the  development  of  DoDAF  products  relative  to  project  organizations  and 
processes  did  provide  useful  insights.  The  products  OV-4  and  OV-5,  in  particular,  were 
useful.  These  products  illustrated  some  complications  with  management  of  the  project 
and  operational  processes. 
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I. 


INTRODUCTION 


A.  BACKGROUND 

The  objective  of  the  Pacific  Tracker  (PT)  is  to  provide  a  ship  with  instrumentation 
quality  radar  and  telemetry  reception  systems  for  data  collection  on  Missile  Defense 
Agency  (MDA)  flight  tests.  The  MDA’s  mission  is  to  develop  systems  to  defend  the 
U.S.,  our  troops,  and  our  Allies  from  ballistic  missile  attacks  (Testing,  2007).  The  term 
“ballistic  missile”  covers  a  spectrum  of  systems.  At  one  end  of  the  spectrum  are  the 
Intercontinental  Ballistic  Missiles  (ICBM)  with  ranges  over  5,500  km.  At  the  other  end 
of  the  spectrum  are  the  Short  Range  Ballistic  Missiles  (SRBM)  with  ranges  as  short  as  80 
km  (NAIC  1998).  This  wide  spectrum  calls  for  flight  test  geometries  that  span  tens  of 
kilometers  to  thousands  of  kilometers  between  the  target  launch  site  and  the  interceptor’s 
launch  site. 

Currently,  all  Missile  Defense  Agency  instrumentation  radars  are  land-based. 
Principally,  these  radars  are  located  at  the  Ronald  Reagan  Ballistic  Missile  Defense  Test 
Site  (RTS)  located  on  Kwajalein  Atoll  in  the  Marshall  Islands  and  the  Pacific  Missile 
Range  Facility  (PMRF)  on  the  Hawaiian  island  of  Kauai.  The  dependency  on  land-based 
radars  produces  significant  gaps  in  radar  coverage  of  planned  ballistic  missile  defense 
system  (BMDS)  tests.  Historically,  targets  simulating  Intercontinental  Ballistic  Missiles 
(ICBM)  have  been  launched  from  Vandenberg  Air  Force  Base  (VAFB),  in  California, 
towards  RTS.  The  distance  between  VAFB  and  RTS  is  nearly  5,600  km.  While  radar 
signature  and  metric  data  of  the  objects  within  the  test  scene  are  required  throughout  the 
trajectory,  most  of  the  trajectory  is  out  of  range  or  view  of  the  land-based  radars.  It  is  this 
gap  in  coverage  that  motivates  the  need  for  ship-based  sensors. 

In  this  thesis,  the  term  “radar  signature  data”  refers  to  the  radar  derived  data  that 
is  used  to  characterize  an  object  so  that  it  may  be  differentiated  from  other  objects. 
Metric  data  refers  to  the  motion  and  location  of  the  object. 


1 


More  recently,  MDA  has  launched  targets  from  Kodiak,  an  Alaskan  island 
famous  for  its  bears.  MDA  has  also  launched  targets  simulating  Medium  Range  Ballistic 
Missiles  (MRBMs)  and  SRBMs  in  various  locations  across  the  Pacific  from  U.S.  Air 
Force  C-17  aircraft  and  from  the  sea-based  Mobile  Launch  Platform,  the  ex-USS  Tripoli. 
Land  on  which  to  base  a  radar  is  simply  not  available  in  most  cases.  The  mobile  nature 
of  the  PT  would  allow  MDA  to  greatly  increase  the  radar  and  telemetry  coverage  on 
various  tests  locations  across  the  Pacific.  In  order  to  meet  data  collection  requirements, 
MDA  has  decided  to  convert  the  S.S.  Beaver  State  to  host  the  X-Band  Test  Radar  (XTR- 
1)  and  the  second  Transportable  Telemetry  System  (TTS-2).  (The  TTS-1  is  currently 
installed  on  MV  Pacific  Collector.) 


Figure  1.  The  S.S.  Beaver  State  as  it  is  being  towed  from  Suisun  Bay  Reserve  Fleet 

in  Benicia,  CA  to  be  temporarily  berthed  at  Alameda,  CA.  (T.  Amundsen, 
personal  communication,  4  April  2008) 
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S.S.  Beaver  State  is  a  former  cargo  ship  that  was  converted  to  a  crane  ship.  The 
purpose  of  a  crane  ship  is  to  unload  or  load  other  ships  at  ports  with  inadequate  facilities. 
This  sort  of  ship  may  be  used  to  help  put  ashore  a  surge  of  materiel  to  support  sustained 
combat  operations.  When  Beaver  State  was  converted  to  a  crane  ship,  three  large  cranes 
were  installed.  To  power  the  cranes,  two  1200  kW  diesel  generators  were  also  added. 
This  size  and  number  of  generators  are  needed  to  reliably  provide  electrical  power  to  the 
radar.  The  size  of  the  ship  and  generators  make  Beaver  State  suitable  to  host  the  XTR-1 
and  TTS-2  systems  and  become  Pacific  Tracker. 


In  the  course  of  converting  Beaver  State  into  Pacific  Tracker,  the  large  cranes  will 
be  removed  and  other  modifications  to  the  ship  will  be  necessary  to  host  the  XTR-1  and 
the  TTS-2.  There  are  five  major  efforts  in  the  conversion  process: 

1 .  Ship  reactivation; 

2.  Modification  of  the  ship  to  host  the  primary  sensors,  the  adjunct  systems, 
and  the  respective  operators; 


3.  Installation  and  integration  of  the  primary  sensors  and  adjunct  systems; 

4.  Development,  installation,  and  accreditation  of  the  communications 
system;  and 

5.  Coast  Guard  certification. 


The  major  engineering  efforts  in  the  conversion  process  that  are  considered  in  this 
thesis  are:  1)  The  design  of  the  modification  for  the  ship  to  host  the  radar,  telemetry, 
adjunct  systems,  and  the  respective  operators;  and  2)  the  design  of  the  communications 
system.  This  thesis  will  review  the  history  of  these  two  aspects  of  this  conversion 
process,  review  DoDAF  1.5,  assess  the  applicability  of  DoDAF  1.5  to  the  Beaver  State 
conversion  process,  and  suggest  opportunities  for  improvement  of  similar  MDA  test  asset 
development  programs. 
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B.  PURPOSE 


The  purpose  of  this  thesis  is  to:  1)  Describe  the  conversion  of  SS  Beaver  State 
into  SS  Pacific  Tracker,  a  project  that  did  not  incorporate  DoDAF  methodology;  2) 
Assess  whether  incorporating  DoDAF  would  have  improved  the  way  the  project  was 
done;  and  3)  Provide  recommendations  on  incorporating  DoDAF  into  other  MDA  test 
asset  development  projects. 

C.  RESEARCH  QUESTIONS 

The  following  questions  will  be  addressed  in  this  thesis: 

1 .  How  was  the  Beaver  State  conversion  project  conducted? 

2.  What  is  DoDAF? 

3.  What  DoDAF  products  might  have  been  produced  to  support  the  project? 

4.  How  may  have  the  DoDAF  methodology  changed  the  way  the  project  was 
done? 

5.  Would  the  DoDAF  methodology  have  been  useful  to  the  project  or  be 
useful  in  future  MDA  test  asset  development  projects? 

D.  BENEFITS  OF  STUDY 

This  thesis  will  document  practical  lessons  derived  from  the  Beaver  State 
conversion.  Recommendations  will  be  provided  on  the  application  of  the  derived  lessons 
to  other  MDA  one  of  a  kind,  or  few  of  a  kind,  test  asset  development. 

E.  SCOPE  AND  METHODOLOGY 

I.  Scope 

The  thesis  will  be  limited  to  the  applicability  of  DoDAF  1.5  to  the  design  of  the 
modifications  for  the  ship  to  host  the  radar,  telemetry,  adjunct  systems,  and  the  respective 
operators;  and  the  design  of  the  communications  system. 
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2.  Methodology 


The  methodology  used  in  this  thesis  research  consists  of  the  following  steps: 

1.  Review  other  ships  MDA  has  used  for  BMDS  testing,  and  review  project 
history  of  the  conversion. 

2.  Review  DoDAF. 

3.  Develop  a  sample  of  DoDAF  products  that  could  have  been  produced  for 
the  conversion. 

4.  Assess  whether  the  DoDAF  approach  would  have  been  useful  to  the 
project  and  its  utility  for  future  MDA  test  asset  developments 
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II.  HISTORY  OF  THE  BEAVER  STATE  CONVERSION 


A.  BACKGROUND 

1.  MDA  Flight  Testing 

The  MDA’s  mission  is  to  develop  systems  to  defend  the  U.S.,  our  troops,  and  our 
Allies  from  ballistic  missile  attacks  (Testing,  2009).  Missile  Defense  flight  tests  are 
designed  to  provide  the  Ballistic  Missile  Defense  System  (BMDS)  with  test  scenarios 
sufficiently  similar  to  hostile  conditions  to  ascertain  or  demonstrate  BMDS  performance 
against  the  threat.  The  term  “threat”  refers  to  the  ballistic  missiles  of  hostile  or 
potentially  hostile  nations.  The  term  “ballistic  missile”  refers  to  “Any  missile  that  does 
not  rely  upon  aerodynamic  surfaces  to  produce  lift  and  consequently  follows  a  ballistic 
trajectory  when  thrust  is  terminated”  (MDA  Glossary,  n.d.).  Ballistic  missiles  include  a 
variety  of  systems.  The  largest  and  longest  ranged  systems  are  the  Intercontinental 
Ballistic  Missiles  (ICBM).  For  example,  the  Russian  SS-18  Mod  5  has  a  range  of  over 
9,600  km.  The  much  smaller  Russian  SS-21  Mod  2,  a  Short  Range  Ballistic  Missile 
(SRBM),  has  a  range  of  only  75  km  (NAIC  1998).  In  order  to  test  BMDS  against  this 
wide  variety  of  missile  systems,  flight  test  geometries  often  span  hundreds  of  kilometers 
for  the  SRBM  scenarios  to  thousands  of  kilometers  for  the  ICBM  scenarios. 

The  BMDS  is  “An  integrated  system  that  employs  layered  defenses  to  intercept 
missiles  during  their  boost,  midcourse,  and  terminal  flight  phases”  (MDA  Glossary,  n.d.). 
Today’s  BMDS  architecture  includes  satellites,  radars,  interceptor  missiles,  and  battle 
management  systems.  The  BMDS  uses  satellites  and  radars  to  detect  and  track  threats 
once  they  have  been  launched.  The  battle  management  system  uses  track  information 
from  the  satellites  and  radars  to  launch  interceptor  missiles  toward  the  approaching 
threat.  The  interceptor  missiles  are  designed  to  collide  with  and  destroy  the  approaching 
threat  missiles.  A  test  scenario  will  often  include  a  target  missile  launch  towards  the 
BMDS  in  such  a  manner  as  to  simulate  a  hostile  engagement. 
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To  characterize  a  BMDS  test,  MDA  collects  information  from  a  variety  of 
instrumentation.  Typical  instrumentation  includes  radars,  infrared  imagers,  visible 
imagers,  and  various  sensors  placed  onboard  the  target  missiles.  Instrumentation  radars 
are  used  to  collect  metric  and  signature  data  on  the  test  scene  to  confirm  the 
characteristics  of  the  target  missile  and  the  threat  scene  presented  to  the  BMDS.  Various 
sensors  placed  onboard  target  missiles  may  include  thermocouples  and  motion  sensors 
that  are  designed  to  help  characterize  the  target’s  performance.  Data  from  the  sensors 
onboard  the  target  missiles  are  telemetered  to  surface  receivers.  In  a  similar  manner,  data 
from  the  interceptor  missiles  may  also  be  telemetered  to  surface  receivers. 

Currently,  all  Missile  Defense  Agency  instrumentation  radars  in  the  Pacific  are 
land-based.  The  premier  radars  are  part  of  the  Kieman  Reentry  Measurements  Site 
(KREMS)  at  the  Reagan  Test  Site  (RTS)  in  the  Marshall  Islands  (RTS,  n.d.).  Other 
significant  radar  assets  are  at  the  Pacific  Missile  Range  Facility  (PMRF)  on  the  Hawaiian 
island  of  Kauai.  The  dependency  on  land-based  radars  can  produce  significant  gaps  in 
radar  coverage  of  planned  ballistic  missile  defense  system  (BMDS)  tests,  and  to  avoid 
data  gaps,  less  realistic  engagement  test  geometries  might  be  used.  Historically,  targets 
simulating  Intercontinental  Ballistic  Missiles  (ICBM)  have  been  launched  from 
Vandenberg  Air  Force  Base  (VAFB)  in  California  towards  the  U.S.  Army  Kwajalein 
Atoll  (USAKA)  Reagan  Test  Site  (RTS)  in  the  Marshall  Islands.  While  signature  and 
metric  data  are  required  along  the  entire  length  of  the  trajectory,  with  a  ground  track 
covering  5,600  km,  most  of  the  trajectory  is  out  of  sight  and  view  of  the  land-based 
radars  due  to  the  curvature  of  the  earth. 

An  instrumentation  radar  placed  upon  an  appropriately  positioned  ship  would 
close  much  of  the  gap  in  radar  coverage  in  a  VAFB  to  RTS  trajectory.  A  ship-based 
radar  could  also  provide  greatly  improved  coverage  of  targets  launched  from  Kodiak, 
Alaska  and  other  locations  in  the  Pacific.  MDA  has  also  launched  target  missiles 
simulating  MRBMs  and  SRBMs  in  various  remote  locations  across  the  Pacific.  In 
addition  to  launching  targets  from  land  bases,  MDA  has  also  air-  and  sea-launched 
targets.  MDA  has  used  U.S.  Air  Force  C-17  aircraft  to  air  launch  a  target  over  the  Pacific 
(News  release  05-NEWS-0009,  2005).  Near  the  Hawaiian  island  of  Kauai,  MDA  has 
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used  the  Mobile  Launch  Platform  (MLP),  the  ex-USS  Tripoli.  In  June  of  2008,  MDA 
conducted  a  flight  test  off  of  Kauai  where  both  the  target  and  the  interceptors  were 
launched  from  vessels  at  sea.  The  target  SRBM  was  launched  from  the  MLP.  Then,  two 
interceptor  missiles  fired  from  the  USS  Lake  Erie  destroyed  the  target  (Successful  Sea- 
Based  Missile  Defense  Intercept).  MDA  has  requirements  to  collect  radar  data  across  the 
Pacific.  A  ship-based  radar  could  have  allowed  MDA  to  greatly  increase  the  radar 
coverage  of  these  various  test  locations  across  the  Pacific.  MDA’s  solution  to  close 
many  of  the  radar  data  collection  gaps  across  the  Pacific  is  the  XTR-1  radar  aboard  the 
ship.  Pacific  Tracker. 

2.  Some  Other  Sea-Based  Sensor  Platforms  MDA  Has  Used  to  Support 
Testing 

The  use  of  sea-based  instrumentation  to  support  flight  testing  is  not  a  new 
concept.  MDA  has  employed  a  number  of  instrumented  sea-based  platforms  to  support 
flight  tests.  These  sea-based  platforms  include  the  MV  Pacific  Collector,  the  USAV 
Worthy,  the  Mobile  Aerial  Target  Support  System  (MATSS),  the  USNS  Observation 
Island  (OBIS),  and  the  Sea-Based  X-band  radar  (SBX).  None  of  these  vessels  were 
originally  designed  or  built  to  support  missile  testing.  Each  vessel  was  designed  and  built 
for  another  function.  However,  in  each  case,  the  vessels  were  modified  in  order  to  accept 
the  specialized  instrumentation  used  in  BMDS  testing.  The  instrumentation  on  Pacific 
Collector  and  Worthy  (Range  Safety,  n.d.)  was  developed  and  integrated  on  the  ships 
specifically  to  support  BMDS  flight  testing.  MDA  developed  the  SBX  to  be  part  of  the 
operational  BMDS  (Testing,  2009).  Even  though  the  primary  purpose  of  the  SBX  is  not 
flight  testing,  MDA  has  been  successful  in  collecting  data  with  the  SBX  on  MDA  flight 
tests  (News  release  07-NEWS-0028,  2007).  The  MATSS  and  OBIS  were  originally 
developed  for  other  related  purposes.  The  PMRF  developed  MATSS  to  support  naval 
weapons  testing.  The  radars  on  OBIS  are  used  to  collect  data  on  foreign  ballistic  missile 
tests  (Cobra  Judy,  n.d.).  However,  the  two  systems,  MATSS  and  OBIS,  lend  themselves 
well  to  supporting  MDA  flight  tests. 
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a.  MV  Pacific  Collector 


Figure  2.  The  MV  Pacific  Collector.  The  twin  7m  dishes  of  the  Transportable 

Telemetry  System  are  seen  in  the  aft  section  of  the  ship  (T-AGS-29,  n.d.). 

Pacific  Collector  (PC)  is  pictured  in  Figure  2.  The  ship  is  the  former 
Texas  Clipper  II,  a  school  ship  for  the  Texas  A&M  University  maritime  program.  Prior 
to  serving  as  a  school  ship,  the  vessel  was  the  USNS  Chennault  (T-AGS-29,  n.d.).  The 
MDA  engaged  the  Maritime  Administration  (MARAD)  to  manage  the  modification  and 
operation  of  the  Texas  Clipper  II.  Shortly  after  the  modification,  the  Texas  Clipper  II 
was  renamed  Pacific  Collector.  The  installation  of  the  Transportable  Telemetry  System- 
1  (TTS-1)  soon  followed  in  late  2006.  The  twin  7m  dishes  and  control  shelters  can  be 
seen  on  the  aft  section  of  the  PC.  The  PC  was  developed  specifically  by  MDA  to 
perform  flight  test  telemetry  data  collection  in  the  broad  ocean  area  (BOA)  where 
telemetry  assets  were  not  otherwise  available.  The  PC  and  TTS-1  system  have  collected 
data  successfully  on  several  missions  since  late  2006.  The  current  home  port  for  the  PC 
is  Portland,  Oregon. 
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DISPLACEMENT 

5,360  T 

LENGTH 

393  ft 

BEAM 

54  ft 

DRAFT 

31  ft 

PROPULSION 

2  ALCO  251  V-I2  DIESEL  ENGINES,  SINGLE 

SHAFT,  3,400  SHP 

Table  1 .  MV  Pacific  Collector  Specifications 


Figures.  US  AV  Worthy 


The  USAV  Worthy,  pictured  in  Figure  3,  is  the  former  Stalwart  Class 
Ocean  Surveillance  Ship  USNS  Worthy  (USNS  Worthy,  n.d.).  The  U.S.  Army  Kwajalein 
Atoll  (USAKA)  acquired  the  ship  in  1995  and  installed  the  Kwajalein  Missile  Range 
Safety  System  (KMRSS)  “to  support  TMD  related  remote  site  launch  activities”  (Range 
Safety,  n.d.).  TMD  in  this  case  stands  for  Theater  Ballistic  Missile  Defense.  The 
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primary  purpose  of  the  KMRSS  is  to  terminate  powered  flight  of  an  errant  missile.  The 
KMRSS  uses  redundant  dishes  to  reeeive  S-Band  telemetry  data  from  the  missile.  The 
data  includes  the  missile’s  position,  velocity,  heading,  and  other  factors.  This  data  is  then 
processed  to  predict  an  impact  point.  If  the  calculated  impact  point  threatens  a  protected 
area,  then  a  command  is  sent  over  UHF  to  terminate  thrust  (Range  Safety,  n.d.). 


DISPLACEMENT 

2,262  LT 

LENGTH 

224  ft 

BEAM 

43  ft 

DRAFT 

15  ft 

PROPULSION 

4  Caterpillar  398D 

Table  2.  USA  V  Worthy  Specifications  (Missile  Range  Instrumentation  Ships, 

2008) 


b.  Observation  Island 


Figure  4.  Observation  Island:  The  S-Band  phased  array  is  seen  on  the  aft  deck,  and 

the  X-Band  radar  is  seen  atop  the  house,  aft  of  the  smokestack  (USNS 
Observation  Island,  2001). 
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The  ship  was  originally  launched  in  1953.  The  Navy  acquired  the  ship 
three  years  later  for  use  as  a  fleet  ballistic  missile  test  ship.  OBIS  was  kept  in  reserve 
from  1972  to  1977  before  it  was  converted  to  a  missile  range  instmmentation  ship. 
Observation  Island  is  currently  operated  by  the  Military  Sealift  Command  (MSC)  for  the  U.S. 
Air  Force  Technical  Applications  Center.  The  ship  is  host  to  S-Band  phased  array  radar  and 
X-Band  dish  radar.  The  OBIS  is  used  for  “worldwide,  monitoring  compliance  with  strategic 
arms  treaties  and  supporting  U.S.  military  weapons  test  programs”  (Missile  Range 
Instrumentation  Ships,  2001).  The  radars  are  collectively  known  as  COBRA  JUDY  (Cobra 
Judy  Radar  System,  n.d.). 


DISPLACEMENT 

17,015  LT 

LENGTH 

564  ft 

BEAM 

76  ft 

DRAFT 

28  ft 

PROPULSION 

Steam,  7180.25  kW 

Table  3.  USNS  Observation  Island  Specifications  (USNS  Observation  Island, 

2001) 


c.  SBX 


Figure  5.  Sea-Based  X-Band  Radar:  The  X-Band  radar  is  under  the  large  center 

dome  (SBX,  2007). 


13 


The  Sea-Based  X-Band  Radar  (SBX)  is  unique  for  its  physical  design  but 
also  because  it  is  part  of  the  operational  BMDS  (Testing,  2009).  The  twin-hulled  vessel 
is  based  on  a  fifth-generation  self-propelled,  semi-submersible  oil  drilling  platform.  The 
top  of  the  dome  is  over  280  ft.  above  the  keel.  The  powerful  radar  “can  be  positioned  to 
cover  any  part  of  the  globe”  (SBX,  2007).  The  SBX  is  able  to  support  BMDS  testing; 
however,  it  is  part  of  the  operational  BMDS.  As  part  of  the  BMDS,  it  is  designed  to  track 
and  discriminate  between  a  hostile  warhead  and  possible  decoys  (SBX,  2007). 


DISPLACEMENT 

^50,000  T 

LENGTH 

390  ft 

BEAM 

240  ft 

DRAFT 

133  ft 

PROFUSION 

4  Siemens  3401.387  kW  Electric  Motors 

Tabled.  SBX  specifications 


3.  Pacific  Tracker  Concept 

The  concept  behind  Pacific  Tracker  is  to  place  a  test  range  instrumentation 
quality  radar,  comparable  to  radars  at  USAKA,  on  a  ship  that  can  be  positioned  anywhere 
in  the  Pacific.  Such  flexibility  would  provide  radar  coverage  on  BMDS  flight  test 
scenarios  that  now  have  significant  gaps  due  to  the  distance  from  land-based  test  range 
instrumentation  radar  assets. 

Data  from  such  a  radar  would  be  valuable  for  multiple  reasons.  One  is  to 
characterize  test  events.  For  example,  a  radar  can  be  used  to  determine  the  time- 
dependent  position  and  motion  of  various  test  objects,  associated  hardware,  and  debris. 
The  test  objects  may  include  the  mock  warhead  of  an  offensive  missile,  possible  decoys, 
and  the  interceptor  kill  vehicle  (KV).  Associated  hardware  may  include  spent  rocket 
motors  and  hardware  that  is  dispersed  when  rocket  stages  separate  or  test  objects  are 
deployed.  Debris  may  include  hot  chunks  of  combustion  by-products  ejected  from  solid 
rocket  motors  or  the  fragments  produced  by  an  intercept  event.  While  systems  utilizing 
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Global  Positioning  Satellite  (GPS)  are  able  to  produce  data  sufficiently  accurate  to  be 
used  to  determine  position  and  motion  of  many  larger  objects,  many  objects  are  too  light 
or  small  to  carry  the  equipment  necessary  to  support  transmitting  GPS  derived  metric 
data. 

In  order  to  meet  the  radar  data  collection  requirements,  MDA  developed  the  X- 
Band  Test  Radar  (XTR-1)  with  the  intent  to  place  the  radar  on  a  suitably  sized  ship.  The 
XTR-1  is  a  dual,  X  and  S,  band  radar  with  an  11m  dish  antenna.  After  the  Pacific 
Tracker  program  was  started,  MDA/DTR  decided  to  add  the  other  Transportable 
Telemetry  System  (TTS-2)  to  Pacific  Tracker.  TTS-2  is  a  duplicate  of  the  TTS-1  on 
Pacific  Collector,  also  with  dual  7m  dishes. 

B.  PACIFIC  TRACKER  PROJECT 

I.  Mission 

The  mission  of  the  Sea-Based  Platform  Product  Office  (SBP)  is  to  maintain, 
operate,  and  develop  sea-based  platforms  to  support  MDA  flight  test  activities.  The  SBP 
was  initially  formed  in  July  2007.  The  first  two  platforms  in  SBP’s  portfolio  were  the 
telemetry  collection  ship  Pacific  Collector  and  the  Mobile  Launch  Platform  (MLP).  The 
MLP  is  the  ex-USS  Tripoli,  a  former  Iwo  lima  class  amphibious  assault  ship.  The 
primary  function  of  the  MLP  is  to  serve  as  a  launch  platform  for  target  missiles,  similar 
to  Scuds,  for  BMDS  testing.  The  MLP  is  operated  as  a  live-aboard  barge  and  is  towed  by 
the  former  fleet  tug,  Narragansett.  With  the  completion  of  the  24  August  2007 
Acquisition  Strategy  Panel  (ASP),  DTR  assigned  the  development  effort.  Pacific 
Tracker,  to  the  SBP.  Responsibility  for  the  ship  passed  from  the  Radar  Product  Branch 
to  the  SBP. 

The  initial  tasking  of  the  SBP  was  to  finalize  ship  selection  and  convert  the 
selected  ship  to  accommodate  the  XTR-1  radar.  Once  Beaver  State  was  selected,  the 
SBP  had  to  complete  five  major  efforts  to  convert  Beaver  State  to  Pacific  Tracker.  The 
five  major  efforts  in  the  conversion  process  are:  1)  Ship  reactivation;  2)  Modification  of 
the  ship  to  host  the  primary  sensors,  the  adjunct  systems,  and  the  respective  operators;  3) 
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Installation  and  integration  of  the  primary  sensors  and  adjunct  systems;  4)  Development, 
installation,  and  certification  of  the  communications  system;  and  5)  Coast  Guard 
certification.  This  thesis  is  primarily  centered  on  the  utility  of  DoDAF  for  the  ship 
modifications  necessary  to  host  the  radar  and  the  development  of  the  communications 
system.  The  five  major  efforts  are  described  in  more  detail  below. 

1.  Ship  reactivation:  Covers  all  actions  to  return  the  ship  to  sea- worthy 
condition.  Based  upon  the  ASP  decision,  the  ships  considered  for  conversions  were  all 
U.S.  government-owned  and  mothballed  in  the  inactive  fleet.  Mothballed  is  used  here  to 
describe  measures  taken  to  protect  the  ship  and  equipment  from  corrosion  or 
deterioration.  At  a  minimum,  the  preservation  measures  needed  to  be  removed  and  the 
equipment  returned  to  operating  condition.  Repairs  would  be  needed  to  address 
deficiencies  in  the  ship’s  condition  at  the  time  of  the  mothballing  and  to  address 
deficiencies  resulting  from  deterioration  that  occurred  while  mothballed.  Part  of  the  ship 
selection  process  took  into  account  the  overall  condition  of  the  ships. 

2.  Modification  of  the  ship  to  host  the  primary  sensors,  the  adjunct  systems, 
and  the  respective  operators:  The  ship  selected  for  conversion  would  require 
modifications  to  accommodate  the  primary  sensors,  XTR-1  and  TTS-2.  Modifications 
necessary  to  support  XTR-1  include:  electrical  distribution,  a  foundation  for  the  radar 
antenna,  and  a  control/computer  room.  Because  the  TTS-2  had  already  been  built  and  the 
XTR  was  being  assembled,  the  first  approach  was  to  have  the  XTR  and  TTS  programs 
develop  respective  interface  control  documents  (ICDs).  Then  the  ship  modifications 
would  be  designed  to  match  the  ICDs. 

This  was  the  approach  taken  for  installing  the  TTS-1  temporarily  on  the  MLP  and 
then  permanently  on  Pacific  Collector.  The  TTS  was  designed  to  be  a  self-sufficient 
system  needing  only  a  relatively  flat  piece  of  land  or  deck  to  sit  on.  It  had  its  own  power 
system,  SATCOM  system,  control  room,  and  antenna  base.  This  was  not  the  case  with 
the  XTR-1.  XTR-1  had  requirements  for  power,  SATCOM,  control  room,  and  antenna 
base.  The  XTR-1  could  not  simply  be  bolted  on  the  ship.  Significant  changes  had  to  be 
made  to  the  ship  to  accommodate  the  XTR-1. 
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3.  Installation  and  integration  of  the  primary  sensors  and  adjunct  systems: 
This  phase  is  when  the  sensors  are  brought  to  the  ship  and  installed.  It  also  includes  the 
time  necessary  to  restore  the  sensors  to  working  condition  once  installed  on  Pacific 
Tracker. 

4.  Development,  installation,  and  accreditation  of  the  communications 
system:  Initially  the  communication  system  was  seen  to  be  part  of  the  XTR;  however, 
with  the  addition  of  the  TTS-2,  this  effort  shifted  to  SBP  to  work.  The  initial  concept 
primarily  centered  on  test  range  communications  and  data  transmission.  As  requirements 
for  test  range  communications  and  data  transmission  were  developed,  requirements 
necessary  to  support  XTR  and  TTS  operations  and  maintenance  surfaced.  Accreditation 
of  the  communication  system  also  became  an  issue  because  the  Tracker  had  to  interface 
with  other  DoD  assets  on  the  Global  Information  Grid  (GIG). 

5.  Coast  Guard  (CG)  certification:  Prior  to  a  ship  being  authorized  to  sail,  it 
must  be  in  a  condition  that  meets  Coast  Guard  regulations.  The  CG  certification  process 
generally  consists  of  a  series  of  inspections  by  the  CG  or  the  American  Bureau  of 
Shipping  (ABS).  “A  tax-exempt  non-governmental  organization  (NGO),  ABS  has  been 
commissioned  by  the  U.S.  government  and  the  USCG  to  act  in  many  maritime  matters 
that  relate  directly  to  the  safety  of  life  and  property  at  sea”  (ABS  Fact  Sheet,  2005). 

2.  Organization 

The  SBP  at  the  start  of  the  project  consisted  of  two  individuals:  the  government 
project  manager  and  one  contractor  employee.  The  project  manager  had  experience  with 
leading  prior  MDA  test  asset  development  efforts.  These  previous  efforts  were  focused 
on  the  development  of  an  infrared  (IR)  imaging  sensor  and  extensive  modification  of 
aircraft  to  host  the  new  IR  sensor.  The  contractor  employee,  a  retired  Navy  skipper,  had 
extensive  experience  with  ships.  The  organization  was  typical  of  project  management  in 
that  the  Pacific  Tracker  Project  Manager  (PTPM)  was  not  anybody’s  supervisor  and  had 
almost  no  formal  contractual  control.  He  was  able  to  restrict  the  flow  of  money; 
however,  that  was  only  the  coarsest  form  of  control.  The  PTPM  provided  funding 
directly  to  three  organizations:  Johns  Hopkins  University/ Applied  Physics  Laboratory 
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(JHU/APL),  NSWC  Corona  Division,  and  MARAD  HQ.  The  bulk  of  the  funding, 
roughly  97%,  went  to  MARAD.  MARAD  and  NSWC  received  funds  via  Military 
Interdepartmental  Purchase  Request  (MIPR).  MDA  had  a  contract  with  JHU/APL,  and 
the  PTPM  was  the  task  manager  for  that  contract. 


Figure  6.  Organization  of  the  Pacific  Tracker  and  major  sensors  projects. 


The  PTPM  assigned  JHU/APL  to  provide  detailed  engineering  analysis,  as 
needed,  and  to  provide  systems  engineering  to  support  to  the  Pacific  Tracker 
development  efforts.  The  Radar  Development  Branch  selected  NSWC  Corona  to  develop 
the  communications  system  for  the  XTR-1  mission  equipment.  Corona  was  experienced 
with  integrating  SATCOM  with  MDA  test  assets.  Corona  had  developed  the  SATCOM 
system  linking  TTS-1  and  TTS-2  and  successfully  revamped  the  SATCOM  on  the  MLP 
to  name  two  projects.  MARAD  was  assigned  to  make  recommendations  for  the  ship 
selection;  to  re-activate  the  ship;  to  modify  the  ship;  and  to  gain  CG  certification. 

3.  Acquisition  Approach 

MDA  considered  several  approaches  for  acquiring  a  ship  to  become  Pacific 

Tracker.  Among  the  approaches  considered  were  a  new  acquisition — designing  and 
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building  a  new  special  purpose  ship;  drawing  a  ship  from  the  U.S.  Inactive  Reserve  Fleet 
(which  is  also  sometimes  referred  to  as  the  MARAD  option);  or  a  lease  arrangement  with 
a  ship  owner/operator.  MDA/DTR  considered  designing  and  building  a  special  purpose 
ship  and  quickly  deemed  the  expected  costs  to  be  too  high  based  upon  a  recent  Navy 
contract  award.  The  Navy  had  recently  selected  the  design  and  build  new  approach  for 
its  Cobra  Judy  replacement  program.  In  2006,  the  Navy  made  a  “$199M  contract  award 
for  the  design  and  construction”  (VT  Halter,  2006)  of  a  new  ship  based  upon  the  existing 
T-AGS  39  design.  The  $199M  price  tag  for  the  Cobra  Judy  replacement  far  exceeded 
MDA’s  budget  for  Pacific  Tracker.  MDA  considered  two  options  in  more  detail:  1) 
drawing  a  ship  from  the  U.S.  Inactive  Reserve  Fleet  and  2)  a  lease  arrangement  with  a 
ship  owner  and  operator. 

The  acquisition  of  Pacific  Collector  followed  the  approach  of  drawing  a  ship  from 
the  U.S.  Inactive  Reserve  Fleet.  Given  the  success  of  Pacific  Collector,  MDA  embarked 
on  the  same  approach  with  Pacific  Tracker.  While  MARAD  was  conducting  the  initial 
assessment  of  available  ships  in  the  inactive  reserve  fleet  for  MDA,  Edison  Chouest  (an 
offshore  vessel  services  company)  approached  MDA  with  the  Lease  option.  Edison 
Chouest  proposed  to  modify  one  of  their  vessels  to  support  XTR  requirements  and  then 
operate  the  ship  for  MDA  under  a  ten-year  lease.  Once  MARAD  had  completed  the 
initial  assessment,  MDA  performed  a  business  case  analysis  of  the  three  options  in  the 
summer  of  2007.  The  results  are  shown  in  Table  5.  The  Director,  Test  Resources 
presented  these  results  to  MDA’s  Acquisition  Strategy  Panel  (ASP)  on  24  August  2007. 


Estimator 

Total  Ship  Outlays  (SM) 

FYO® 

FY109 

fno 

FYH 

FY12 

FYI^ 

Total 

FYDP 

FVDP  Siavjiii3£ 
V5.  Lease 

DOBE 

MARAD 

Options 

Beaver  State 

12  7 

13.0 

21.4 

21.8 

222 

227 

113  8 

28.6 

Diamond  State 

i3.e 

16.1 

21.4 

21.9 

22.3 

22.8 

1171 

25.3 

New  Ship  (8500  LTns) 

970 

148.8 

21.0 

21.6 

21  9 

224 

3326 

LeSSG  (based  or  Edison  Cbousesl) 

16.E 

24.1 

24  7 

25,2 

25,7 

26,2 

142,4 

Table  5.  Projected  costs  by  FY for  Pacific  Tracker  development  and  operation 


As  shown  in  Table  5,  MDA’s  procurement  group  estimated  MDA’s  costs  for  the 
three  approaches  to  develop  and  operate  Pacific  Collector.  Additionally,  within  the 
MARAD  option,  two  different  ships  were  considered.  DOBE  estimated  that  the  design, 
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conversion,  and  XTR  integration  would  occur  within  FY08  and  FY09.  These  estimates 
allowed  time  for  the  sensor  integration  but  did  not  include  costs  for  the  XTR  integration 
or  operation.  These  costs  were  included  when  the  ASP  previously  considered  and 
approved  the  XTR  program  independent  of  ship  platform.  The  costs  for  the  remaining 
years  are  projected  maintenance,  berthing,  and  operation.  The  operational  costs  are  based 
on  eight  data  collection  voyages.  The  duration  of  each  voyage  was  assumed  to  be  21 
days. 

MDA’s  procurement  group  analysis  determined  that  the  New  Ship  approach  was 
the  most  costly  approach  by  a  wide  margin  and  supported  DTR’s  early  rejection.  The 
Lease  approach  did  not  appear  to  offer  any  great  advantage  above  the  MARAD  approach. 
The  Lease  approach  had  the  higher  initial  cost,  higher  operational  cost,  and  of  course,  the 
higher  total  cost.  The  Lease  option  Edison  Chouest  proposed  possibly  offered  the 
advantage  of  fixed,  known  costs  with  the  contractor  assuming  the  risk.  The  fixed  cost 
option  was  only  possible  if  the  requirements  were  fiilly  known  and  not  likely  to  change  in 
a  significant  manner— an  unlikely  scenario  for  the  Pacific  Tracker  project.  MARAD  had 
concluded  that  two  crane  ships,  Beaver  State  and  Green  Mountain  State,  were  best  suited 
to  meet  MDA  requirements.  Beaver  State  and  Green  Mountain  State  were  similar  though 
not  identical  ships  and  either  one  could  meet  the  MDA  requirement  to  host  the  XTR.  The 
difference  in  projected  cost  for  the  conversion  and  activation  phase  of  the  program  was 
driven  by  the  difference  between  the  physical  conditions  of  the  two  ships.  Beaver  State 
was  judged  by  MARAD  to  be  best  in  class. 

4.  Technical  Approach 

The  technical  approach  for  the  Pacific  Tracker  program  was  largely  determined 
by  the  acquisition  decision  to  pull  a  ship  from  the  inactive  reserve  and  modify  it  to  meet 
the  requirements  of  hosting  the  XTR.  At  the  ASP,  some  discussion  was  given  to  the 
ability  of  candidate  ships  to  host  a  TTS.  However,  the  ability  to  host  the  TTS  was  not 
identified  as  a  formal  requirement  until  after  the  ship  selection.  The  formal  requirement 
at  the  time  of  the  ASP  was  to  find  a  ship  with  the  size  and  electrical  power  generation 
capability  to  accommodate  only  the  XTR. 
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At  the  time  of  the  ASP  briefing,  the  technical  approach  had  four  major  steps.  The 
first  step  was  for  the  XTR-1  developer,  Massachusetts  Institute  of  Technology  Lincoln 
Laboratory,  to  produce  an  interface  control  document  (ICD).  “MIT  Lincoln  Laboratory 
is  a  federally  funded  research  and  development  center  chartered  to  apply  advanced 
technology  to  problems  of  national  security”  (MIT/LL,  n.d.).  The  second  step  was  for 
naval  architects,  under  contract  to  MARAD,  to  develop  a  design  in  accordance  with  the 
XTR-1  ICD.  The  third  step  was  for  a  shipyard  to  make  the  modifications  to  the  ship. 
The  fourth  step  was  for  the  XTR  to  be  integrated  on  the  ship,  once  the  shipyard  work  was 
completed.  As  the  program  progressed,  TTS-2  and  the  communications  system  were 
added  to  the  effort.  The  steps  for  TTS  and  the  communications  system  followed  a  path  of 
requirements  definition,  design,  modification,  and  installation  similar  to  XTR- 1 . 

The  first  step  of  developing  the  ICD  was  expected  to  be  straight  forward  for  the 
developer.  The  XTR-1  was  in  a  relatively  advanced  stage  of  development  and  it  already 
was  being  fabricated.  The  XTR-1  ICD  was  expected  to  describe  the  interfaces  between 
the  radar  and  the  ship  as  well  as  identify  other  requirements  for  space,  electrical  power, 
and  cooling  for  the  radar. 

Likewise,  the  second  step  was  expected  to  be  straight  forward  for  the  naval 
architects  to  produce  a  design  to  host  the  radar.  It  was  envisioned  that  the  naval 
architects  would  quickly  produce  a  detailed  design.  There  were  three  major  components 
of  the  design:  the  electrical  system,  structural  modifications,  and  machinery 
(predominantly  a  chilled  water  system  to  cool  the  radar).  It  was  understood  that  the 
electrical  system  would  have  to  be  modified  to  allow  the  radar  to  draw  power  from  either 
diesel  generator.  Structural  modifications  that  included  building  out  rooms  such  as  office 
spaces  and  control  and  computer  rooms  were  expected  to  be  relatively  simple.  While  a 
larger  effort,  even  the  structural  modifications  foundation  for  the  XTR  antenna  was 
considered  to  be  straight  forward.  It  was  thought  the  design  of  chilled  water  cooling 
system  was  largely  a  matter  of  selecting  the  correctly  sized  commercial  system. 

Once  the  modification  design  was  complete,  the  third  step  was  to  compete  the 

modification  work  among  interested  shipyards  and  have  the  winning  shipyard  perform 

the  modifications.  The  modifications  would  be  coupled  with  dry-dock  work  in  the 
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competitive  package.  The  dry-dock  work  would  be  routine  items  necessary  to  aetivate 
the  ship  and  meet  regulatory  requirements.  After  the  shipyard  eompleted  the 
modifications  and  work  in  the  dry-dock,  the  fourth  step  would  be  to  install  the  XTR-1  on 
Pacific  Tracker. 

5.  Schedule  and  Milestones 

The  initial  schedule  that  was  shown  during  the  ASP  briefing  is  shown  in  Figure  7. 
Figure  7  shows  Paeific  Traeker  milestones  in  relation  to  upcoming  FTGs.  FTG  is  the 
designation  for  flight  tests  of  the  Ground-based  Mideourse  Defense  (GMD)  system.  FTG 
seenarios  inelude  the  Vandenberg  to  Kwajalein  trajectories.  The  first  milestone  is  the 
authority  to  proceed  with  ship  aequisition.  The  date  eoineides  with  the  ASP  presentation 
on  24  August  2007.  At  that  time,  the  XTR-1  schedule  showed  that  the  radar  would  be 
ready  to  install  on  the  ship  towards  the  end  of  FY  2008.  The  detail  design  work  prior  to 
entering  into  the  shipyard  was  scheduled  to  begin  September  2007  and  run  approximately 
six  months  to  the  end  of  February  2008.  This  allowed  only  six  months  for  MIT/LL  to 
produee  an  ICD  and  for  MARAD  to  produee  the  detailed  design  to  modify  the  ship  to 
allow  it  to  aecept  the  XTR.  The  next  six  months  were  allotted  to  shipyard  modifieations 
of  the  vessel.  Then  another  six  months  were  allotted  for  the  installation  of  the  radar  on 
the  ship.  After  another  month  of  sea  trials.  Pacific  Tracker  would  be  ready  to  support 
FTG-08. 
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Phase 

FY07 

FY08 

FY09 

FY10 

FY11 

FY12 

FY13 

Upcoming  FTGs 

03a 

★ 

04  05  06 

★  ★★ 

07  08 

★  ★ 

09  10 

★  ★ 

-v| 

Ship  Acquisition  Authority  to 
Proceed 

Radar  Ready  for  Ship  Platform 

A 

Detailed  Design  Work 

1 

1  6  m( 

onths  (01  S 

ept  '07  -  2 

1 - 1 

9  Feb  ’08) 

I - 1 

p 

Reactivation  and  Modification 

1 - 1 - 1 

I - 

6  months 

(01  March  ‘08  -  31  A 

ug  ’08)  I 

Radar  Integration  Onto  Ship 

1 

IH  I  6  months  (01  Sept  ‘08  -  28  Feb  '09)  |  | 

— ^ 

p - 

Sea-Based  Acceptance  Testing 

1 _ 1 

Month  (01 

I _ I 

Mar  ‘09  - 

31  Mar  ’09 

p 

XTR-1  Ready  to  Support  Missions 

A 

Operations  and  Sustainment 

1  1  1  1 

Figure  7.  Schedule  for  the  project  presented  at  ASP  by  DTR 


6.  Design  Evolution  History 

The  design  requirements  for  Pacific  Tracker,  and  hence  the  corresponding  design 
concepts,  underwent  significant  changes  as  the  project  proceeded.  A  few  significant 
milestones  in  the  program  are  used  to  capture  the  then  current  design  requirements  and 
design  concepts  at  those  particular  junctures.  The  first  milestone  will  be  the  ASP 
meeting.  Subsequent  milestones  will  be  SRR,  CDR,  and  contract  award.  Between 
milestones,  the  design  made  significant  changes  due  to  requirement  changes,  improved 
understanding  of  requirements,  and  cost  constraints. 

a.  Acquisition  Strategy  Panel 

At  the  time  of  the  ASP,  MIT/LL  had  yet  to  develop  its  ICD.  There  was 
sufficient  understanding  of  the  requirements  for  electrical  power  and  physical  size  to 
select  a  ship.  However,  those  requirements  were  not  sufficiently  understood  for  the  naval 
architects  to  begin  a  detailed  modification  design.  Several  months  after  the  ASP,  two 
additional  major  requirements  were  added  to  the  program.  First  was  the  addition  of  TTS- 
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2  and  the  second  was  for  XTR-1  to  operate  throughout  a  flight  without  loss  of  data,  even 
with  a  prime  power  causality.  The  impacts  of  those  requirements  are  discussed  in  more 
detail  in  the  following  section  on  the  Systems  Requirements  Review. 

b.  Systems  Requirements  Review 

At  the  SRR,  options  were  presented  for  modifications  to  the  ship  to 
provide:  mission  equipment  electrical  power,  MDA  mission  personnel  berthing,  TTS 
antenna  placement,  and  the  communications  system.  In  this  thesis,  the  term  “mission 
equipment”  is  used  to  denote  the  equipment  associated  with  the  XTR,  TTS,  and 
communications  system.  Between  the  ASP  and  the  SRR,  there  were  two  major  changes 
to  Pacific  Tracker  requirements.  The  first  was  the  addition  of  the  TTS.  The  second 
major  change  was  the  clarification  of  the  requirement  to  supply  reliable  power  to  the 
mission  equipment.  The  power  requirement  was  now  to  have  the  mission  equipment, 
including  the  radar  on  UPS  backup,  sufficient  to  power  the  system  for  30  minutes.  The 
addition  of  TTS  to  the  ship  added  not  only  new  requirements  to  support  the  installation  of 
the  TTS  equipment  but  also  placed  additional  demands  on  berthing,  the  communication 
system,  and  the  electrical  system.  While  the  addition  of  TTS  drove  changes  to  the 
electrical  design,  the  requirement  to  supply  reliable  electrical  power  to  the  mission 
equipment  was  the  biggest  driver.  (The  primary  source  of  information  for  the  systems 
requirements  review  section  is  the  March  2008  Trade  Studies  presented  by  the  PTPM  at 
the  SRR.) 

The  overarching  requirement  for  the  electrical  system  is  to  reliably  meet 
the  mission  equipment’s  power  demand  throughout  the  flight  event.  Prior  to  the  addition 
of  TTS,  the  XTR  ICD  indicated  it  would  draw  about  1280  kVA,  including 
communications,  when  it  was  radiating  at  full  mission  load.  The  TTS  ICD  indicated  its 
load  would  be  another  320  kVA.  The  resulting  total  mission  equipment  load  would  be 
1600  kVA.  The  power  generation  capability  seemed  to  be  more  than  enough  to  meet  the 
mission  equipment’s  expected  load. 
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System 

Total 

XTR-1 

1,265  kVA 

TTS-2 

320  kVA 

Comms 

15  kVA 

Grand  Total 

1,600  kVA 

Table  6.  Power  requirements  based  on  XTR-1  and  TTS  ICDs 

Beaver  State  has  the  capability  to  generate  3900  kW.  She  has  two  750  kW 
steam  turbine  generators  and  two  1200  kW  diesel  generators.  After  taking  into  account 
the  ship’s  expected  load  of  about  600  kW,  there  would  still  be  3300  kW  available  to 
power  the  mission  equipment.  The  power  generation  capability  for  the  generators  is 
expressed  in  kW;  however,  the  load  is  expressed  in  kVA.  A  conversion  is  required  to 
express  the  power  and  the  load  in  the  same  units.  The  MARAD  electrical  design 
engineer  selected  a  power  factor  of  0.8.  Therefore,  the  1600  kVA  load  converts  to  1280 
kW.  The  addition  of  TTS  increased  the  mission  equipment’s  load  by  25%.  However,  the 
generation  capability  was  well  over  two  times  the  expected  load. 

The  “reliably... throughout  the  flight  event’’  portion  of  the  requirement 
produced  a  more  significant  impact  than  adding  the  TTS  load.  “Throughout  the  flight’’ 
meant  from  shortly  before  the  first  launch  until  the  last  splash.  For  ICBM  intercept  tests, 
this  translates  to  a  time  period  of  about  30  minutes.  The  intent  was  for  XTR,  TTS,  and 
the  communications  system  to  remain  fully  functional,  that  is  with  no  loss  of  data,  for  30 
minutes  even  if  the  respective  primary  power  source  was  lost.  MARAD  developed  three 
options  to  meet  the  power  requirement:  1)  Modify  the  switchboard  so  both  diesel 
generators  operate  in  parallel;  2)  Add  a  third  diesel  generator;  and  3)  Add  an 
uninterruptable  power  supply  (UPS)  sufficient  to  power  all  of  the  mission  equipment  for 
30  minutes  of  operations. 

Option  1,  as  shown  in  Figure  8,  has  the  following  features:  1)  Lowest  cost 
of  the  options  considered;  2)  If  one  steam  turbine  generator  or  one  diesel  generator  fails 
(after  missile  launch),  the  UPS  units  will  provide  continuity  of  mission  equipment  power 
for  30  minutes;  and  3)  Failure  of  either  a  diesel  generator  or  diesel  generator  switchboard 
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will  not  interrapt  power  to  S  and  X-Band  High  Voltage  Power  Supplies  (HVPS)  and 
XTR  Antenna  Servo  Motors.  The  major  disadvantage  is  that  it  did  not  meet 
management’s  desire  to  have  all  the  mission  equipment  backed  up  by  a  UPS. 
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Figure  8.  MARAD’s  power  option  1 


Option  2,  as  shown  in  Figure  9,  has  the  following  features:  1)  Failure  of 
any  diesel  generator  or  diesel  generator  switchboard  will  not  interrupt  mission  power. 
The  remaining  diesel  generator  can  maintain  mission  power  without  having  to  rely  on 
UPS  units;  2)  The  mission  power  system  is  completely  isolated  from  the  ship’s  power 
system.  Disruptions  in  the  ship’s  power  system  will  not  affect  mission  operations;  and  3) 
According  to  MARAD,  a  1640  kW  diesel  generator  was  currently  available  from  another 
MARAD  activity.  The  disadvantages  of  this  option  are:  1)  It  is  the  most  expensive  of  all 
the  options;  2)  It  requires  new  auxiliary  machinery  room  and  associated  support  systems 
for  the  diesel  generator  installation  and  a  new  diesel  generator  switchboard;  and  3) 
Additional  engine  room  watch  personnel  would  be  required. 
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Figure  9.  Power  option  2 


Option  3,  as  seen  in  Figure  10,  has  the  following  features:  1)  Failure  of 
any  (or  both)  diesel  generator  will  not  interrupt  mission  power  for  a  minimum  of  90 
minutes,  and  2)  The  mission  power  system  is  eompletely  isolated  from  the  ship’s  power 
system.  Disruptions  in  the  ship’s  power  system  will  not  affect  mission  operations.  The 
disadvantages  of  option  3  are:  1)  It  requires  installing  a  new  diesel  generator  switchboard 
and  Mission  Switchboard,  and  four  400  kVA  UPS  units;  and  2)  Different  voltages  of  the 
ship’s  service  power  system,  450  V,  and  Mission  power  systems,  480  V,  prevent  the 
capability  to  parallel  systems.  Significant  modifications  are  necessary  to  permit 
paralleling  to  the  ship’s  service  switchboard  and  SSTG  governors;  and  3)  The  UPS 
battery  life  expectancy  will  likely  cause  new  batteries  to  be  purchased  every  few  years. 

DT  management  considered  the  power  options  and  projected  costs.  After 
some  additional  discussion,  DT  management  decided  to  relax  the  requirement  for  100% 
UPS  backup  for  all  mission  equipment.  When  the  requirement  was  changed  from  100% 
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UPS  backup  to  100%  backup,  option  1  became  viable.  This  option  uses  one  of  the  diesel 
generators  as  the  primary  power  souree  and  the  other  diesel  generator  as  the  back  up 
power  souree  for  the  radar  transmitters.  Additionally,  option  1  uses  UPS  as  the  baek  up 
power  souree  for  the  other  mission  equipment.  DT  management  directed  the  program  to 
proeeed  with  refining  option  1 . 
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Figure  10.  SRR  power  option  3 


Options  for  berthing  were  also  presented  at  the  SRR.  There  are  not 
enough  berthing  rooms  onboard  the  ship  to  provide  every  member  of  the  ship’s  erew  and 
MDA  mission  crew  with  a  private  room.  If  each  member  of  the  ship’s  erew  had  a  private 
room,  there  would  only  be  enough  state  rooms  to  aeeommodate  eight  MDA  personnel, 
not  the  currently  expeeted  22-29  personnel.  MARAD  developed  three  options  to 
accommodate  additional  personnel.  The  first  option  is  to  utilize  the  existing  staterooms 
without  building  additional  staterooms.  The  seeond  option  is  to  install  24  new  single 
staterooms  and  utilize  six  single  staterooms  eurrently  existing  within  the  ship’s  house. 
The  third  option  was  to  install  30  new  single  staterooms. 
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The  first  option  is  to  use  the  existing  22  single  and  21  double  staterooms 
without  building  additional  staterooms.  The  ship’s  erew  requires  12  single  staterooms  for 
the  lieensed  and  senior  unlicensed  personnel.  For  the  remaining  unlicensed  personnel, 
they  will  be  assigned  to  14  double  staterooms.  The  remaining  ten  single  and  seven 
double  staterooms  would  be  assigned  to  MDA  mission  personnel.  This  would  allow 
MDA  to  place  24  personnel  onboard. 

There  are  a  number  of  issues  associated  with  these  limits.  The  first  issue 
is  the  use  of  only  the  existing  staterooms  severely  constrains  the  staffing  flexibility  for 
both  MDA  and  MARAD.  MDA  will  be  restricted  to  only  24,  just  two  more  than  the 
lower  limit.  The  ship’s  crew  will  be  limited  to  40.  Previously,  when  Beaver  State  was 
active,  she  steamed  with  a  crew  of  39.  The  size  of  the  ship’s  crew  had  yet  to  be 
determined.  The  improved  viewing,  because  the  large  cranes  will  no  longer  restrict  the 
view  from  the  bridge,  may  reduce  the  crew  size  by  three,  according  to  MARAD. 
However,  the  added  MDA  mission  crew  will  likely  increase  the  required  number  in  the 
steward  department.  These  numbers  do  not  account  for  gender.  For  example,  if  there 
were  seven  males  and  seven  females  in  the  MDA  crew  whose  status  would  normally 
place  them  in  a  double  room,  only  one  odd  male  or  odd  female  could  be  berthed  but  not 
both.  The  option  of  only  using  existing  staterooms  does  have  the  advantage  of  having  the 
lowest  cost  of  the  three  options. 

The  second  option  was  to  build  accommodations  on  the  main  deck  in  front 
of  the  house.  These  new  accommodations  would  provide  24  new  single  staterooms  for 
MDA  mission  personnel.  This  option  also  called  for  MDA  to  utilize  another  six  single 
staterooms  in  the  house.  This  would  have  allowed  space  for  30  MDA  mission  people  and 
allowed  the  ship’s  crew  to  reach  a  level  of  35  before  having  to  double  bunk  anyone.  This 
option  met  the  requirements;  however,  it  did  place  limits  on  MDA’s  flexibility.  The  issue 
with  this  option  and  the  third  option  was  cost.  MARAD ’s  cost  estimate  for  building  the 
24  new  staterooms  was  $5M. 

The  third  option  presented  called  for  the  building  of  30  new  staterooms  for 

MDA  mission  personnel.  This  would  have  provided  MDA  with  enough  berthing  to  meet 

its  expectations  and  no  one  on  the  ship’s  crew  would  have  to  double  up.  There  even 
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would  have  been  some  vacant  rooms  to  allow  for  contingency  or  additional  sensors.  This 
option  would  provide  better  living  conditions  for  high  ops  tempo  and  would  provide  the 
most  flexibility  for  staffing  the  ship  and  the  MDA  mission  systems.  The  down  side  was 
the  cost.  By  MARAD’s  estimate,  the  incremental  cost  was  only  $500k  more  for  30 
staterooms  over  the  24  stateroom  plan.  The  recommendation  was  to  go  with  option  3. 

The  initial  plan  for  the  TTS-2  antenna  installation  was  to  place  them  on 
the  hatch  coamings  in  the  open.  This  concept  was  very  similar  to  how  the  TTS-1 
antennas  are  mounted  on  Pacific  Collector.  However,  DT  leadership  clarified  the  TTS 
requirement  to  include  radomes  over  the  antennas.  Leadership  mandated  the  use  of 
radomes  in  order  to  improve  the  lifecycle  maintainability  of  the  TTS-2 ’s  antennas.  The 
issue  with  the  radomes  was  that  nothing  could  be  allowed  to  block  visibility  for  the  wheel 
house.  The  visibility  requirement  is  “...the  view  of  the  sea  surface  is  not  obscured 
forward  of  the  bow  by  more  than  the  lesser  of  two  ship  lengths  or  500  meters  (1,640  feet) 
from  dead  ahead  to  10  degrees  on  either  side  of  the  vessel.  Within  this  arc  of  visibility 
any  blind  sector  caused  by  cargo,  cargo  gear,  or  other  permanent  obstruction  must  not 
exceed  5  degrees.”  (Construction  and  Arrangement,  2004).  Even  the  introduction  of  the 
shortest  feasibly  sized  radome  would  exceed  the  allowable  limits  of  obstruction  if  placed 
on  top  of  the  hatch  coaming. 

The  TTS  developer  initially  provided  a  radome  design  that  called  for  a 
height  of  42  ft.  With  further  discussions  and  analysis  the  TTS  developer  and  the  naval 
architect  determined  the  maximum  feasible  height  for  the  radomes  to  be  37  ft.  A  height 
of  37  ft  could  be  achieved;  however,  there  would  be  regrets  for  the  TTS  operators.  Even 
so,  the  37’  tall  radomes  placed  on  the  hatch  coaming  would  have  blocked  the  view  from 
the  bridge.  Therefore,  three  options,  in  addition  to  the  no  radome  option,  were  developed 
to  explore  methods  to  allow  heights  of  37,  39,  and  42  feet. 

Three  options  were  presented  to  meet  the  combined  requirements  for 
visibility  from  the  bridge  and  protecting  the  antenna:  1)  Limit  the  radomes  to  a  height  of 
37  feet;  remove  hatch  coamings,  and  modify  the  ship’s  main  deck;  2)  Limit  the  radomes 
to  a  height  of  39  feet;  raise  the  wheel  house  one  level;  and  partially  modify  the  ship’s 

deck;  and  3)  Raise  the  wheel  house  two  levels;  without  modifications  to  the  ship’s  deck. 
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MARAD’s  first  option  has  the  advantage  of  being  the  lowest  cost  option 
which  would  allow  radomes  of  any  size.  Nevertheless,  it  would  call  for  an  estimated 
$2.4M  to  remove  the  hatch  coamings  and  build  deck  inserts  strong  enough  to  support  the 
TTS  antennas.  As  shown  in  Figure  12,  the  front  radome  would  still  produce  a  partial 
obstruction.  This  obstruction,  however,  would  be  within  the  allowable  limits.  The 
forward  antenna  was  brought  as  far  aft  as  possible  to  maintain  a  required  60  ft  separation 
between  antennas. 

The  second  option  would  allow  a  greater  separation  between  antennas  and 
a  radome  height  of  39  ft.  It  would  have  also  only  called  for  the  removal  of  one  hatch 
coaming  and  the  corresponding  deck  insert.  However,  it  called  for  the  wheel  house  to  be 
raised  one  level,  approximately  8  ft.  This  may  have  seemed  to  be  the  compromise  option; 
however,  it  was  the  costliest  of  the  three.  While  it  combined  the  advantages,  higher 
radome  height,  and  less  steel  work  on  the  main  deck,  it  also  combined  the  cost  of  major 
steel  work  on  the  main  deck  and  the  cost  of  raising  the  wheel  house. 
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Figure  12.  TTS  antenna  and  deek  configuration  for  option  2 


The  third  option  allowed  for  the  full  sized  radomes,  42  ft,  and  it  avoided 
major  steel  work  on  the  main  deck.  No  hatch  coamings  would  have  to  be  removed; 
however,  the  wheel  house  would  now  have  to  be  raised  two  levels,  or  16  ft.  The  cost  for 
option  3  was  estimated  to  be  $5M.  DT  management  directed  that  option  1  for  the  TTS 
antennas  be  implemented. 


Figure  13.  Option  3  with  42  ft  tall  radomes  and  antennas  mounted  on  hatch  coamings 


The  XTR  and  the  TTS  have  requirements  to  receive  and  transmit  data. 
For  example,  both  systems  will  require  the  ability  to  receive  and  send  pointing  data  in  the 
form  of  an  inter-range  state  vector  (IRV).  In  addition,  it  is  highly  desirable  to  send 
processed  data  from  the  systems  in  real  time  as  they  track  objects  during  the  test  event. 
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PTPM  directed  APL  to  conduct  a  study  to  determine  the  MDA  mission  requirements  for 
communication.  This  study  did  not  address  the  communication  equipment  needed  for 
ship  operations.  Their  summary  conclusion  is  shown  in  Table  7. 


Phase 

Direction 

Critical 

Medium"^ 

Low^ 

P  re -Miss  ion 

Incoming 

198 

1745 

2355 

Outgoing 

175 

1668 

2750 

During  Mission 

Incoming 

190 

1315 

2718 

Outgoing 

175 

4333 

6535 

Post-Mission 

incoming 

45 

1038 

1918 

Outgoing 

45 

2873 

5348 

Pier  Side 

incoming 

0 

2238 

6048 

Outgoing 

0 

2238 

6048 

*  Cumulatjve  totals  (intSude  highe?  priority  traffic) 


Table  7.  APL  summary  conclusions  for  bandwidth  requirements  in  kbs 

APL  recognized  that  the  communication  traffic  would  change  as  the 
system  progressed  from  one  phase  of  the  test  cycle  to  the  next.  The  direction  of  the 
traffic,  whether  incoming  or  outgoing,  needs  to  be  considered  along  with  the  priority  of 
the  traffic.  The  test  event  activity  was  split  into  four  phases:  Pre-Mission,  During 
Mission,  Post-Mission,  and  Pier  Side.  The  term  During  Mission  refers  to  the  time  frame 
beginning  roughly  eight  hours  prior  to  the  beginning  of  the  launch  countdown  until 
several  minutes  after  the  flight  test  event.  Pre-Mission  is  the  time  frame  between  leaving 
the  pier  and  the  start  of  the  During  Mission  phase.  Post-Mission  is  the  time  between  the 
end  of  the  test  event  and  the  ship  arriving  back  at  Portland.  Pier  Side  is  the  time  when 
Pacific  Tracker  is  berthed  at  home  port.  Incoming  traffic  means  the  data  flow  from  shore 
to  the  sensors.  Outgoing  traffic  means  the  data  flow  from  the  sensors  to  the  shore.  APL 
used  three  levels  of  priority:  Critical,  Medium,  and  Low.  Critical  priority  traffic  means 
the  traffic  critically  necessary  to  achieve  the  primary  test  event  objectives,  relative  to  the 
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XTR  and  TTS.  Examples  of  this  type  of  traffic  are  the  inter-range  vectors  used  to  cue 
sensor  tracking.  Without  these  tracking  cues,  the  ability  of  the  XTR  and  TTS  to 
autonomously  acquire  and  track  a  target  is  not  assured.  Medium  priority  traffic  is  needed 
to  support  a  certain  function.  For  example,  Medium  traffic  would  be  providing  real  time 
data,  such  as  video  from  the  booster  sent  via  telemetry  or  XTR  console  display  to  the  test 
range  or  other  sites.  This  could  also  include  such  general  support  as  phone  and  fax 
traffic.  Low  priority  traffic  is  useful  to  support  a  certain  function.  However,  without  this 
traffic,  the  function  would  still  work.  For  example,  Internet  access  may  fall  into  this 
category.  None  of  the  sensors  are  dependent  on  the  Internet  to  function  correctly; 
however,  access  to  the  Internet  for  information  may  help  the  operations  (Zheng,  2008). 

The  existing  communications  equipment  from  TTS-2  includes  three  Fleet 
77  INMARSAT  and  one  wideband  Sea  Tel  2.4  m  dish.  The  TTS  had  been  configured  so 
that  the  critical  data  had  two  paths:  the  Fleet  77  INMARSATS  and  the  Sea  Tel.  The 
medium  and  low  priority  traffic  only  followed  over  the  Sea  Tel.  While  this  configuration 
was  sufficient  for  TTS  alone,  it  did  not  allow  enough  bandwidth  for  the  TTS  and  XTR 
critical  data.  The  PTPM  presented  three  options  to  address  the  shortfall:  1)  one  Sea  Tel 
and  four  INMARSATS;  2)  two  Sea  Tel  systems;  3)  two  Sea  Tels  and  three  INMARSATS. 
The  first  option  called  for  purchasing  additional  Fleet  77  INMARSAT  and  integrating  the 
one  Sea  Tel  and  four  INMARSATS  onto  the  Tracker.  Option  2  called  for  purchasing  a 
second  Sea  Tel  and  installing  only  the  two  Sea  Tels.  The  third  option  called  for  the 
purchase  of  a  second  Sea  Tel  as  in  option  2;  however,  the  three  existing  INMARSAT 
would  also  be  installed  as  a  tertiary  backup  for  the  systems.  DT  management  directed 
option  2  be  pursued. 


c.  Preliminary  Design  Review 

At  the  PDR,  MARAD  showed  some  further  details  on  the  designs 
presented  at  the  SRR,  except  for  the  electrical  design.  The  general  arrangement  for  the 
placement  of  XTR-1  and  TTS-2  had  not  changed.  However,  as  MARAD’s  naval 
architects  refined  the  designs,  additional  questions  surfaced.  Between  the  SRR  and  the 
PDR,  the  naval  architects  had  taken  a  much  closer  look  at  the  XTR-1  requirements  for  the 
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antenna  foundation.  Significant  amount  of  discussion  between  the  naval  architects  and 
the  XTR-1  developers  ensued  to  better  understand  the  stated  requirements.  The  naval 
architects  initially  approached  the  foundation  design  from  a  traditional  mechanical  load 
perspective,  for  example,  determining  what  mechanical  loads,  weight,  torque,  and  so 
forth  must  the  foundation  support.  However,  the  specifications  MIT/LL  had  provided 
were  in  terms  of  stiffness,  and  in  particular,  required  the  foundation  not  to  conduct 
vibration,  which  would  excite  the  natural  resonance  frequency  of  the  XTR-1  antenna 
pedestal. 


d.  Critical  Design  Review 

During  the  progression  from  the  SRR  to  the  CDR,  the  power  requirements 
became  better  understood  and  the  power  margin  shrank.  The  MARAD  design  team 
became  more  concerned  about  the  margin.  MARAD  completed  a  load  analysis.  The 
load  analysis  determined  there  was  still  enough  power;  however,  the  predicted  mission 
equipment  load  had  significantly  increased  from  the  early  indications.  The  predicted 
mission  equipment  load  had  increased  so  much  the  design  for  the  power  system  had  to  be 
changed.  The  concept  at  the  SRR  was  for  the  SSDGs  to  supply  primary  and  backup 
power  for  the  radar  antenna  servos  and  S  and  X  band  high  power  voltage  power  supplies. 
For  simplicity  in  this  section,  the  radar  antenna  servos  and  S  and  X  band  high  power 
voltage  power  supplies  are  referred  to  as  simply,  “the  radar.”  The  other  mission 
equipment,  TTS-2;  XTR-1  control;  communications  equipment;  and  mission  support 
equipment  (cooling  water,  HVAC,  lighting,  and  so  forth),  would  be  powered  by  the 
SSTGs  with  backup  power  being  provided  by  the  UPS  and  the  other  SSDG.  (The 
primary  source  of  information  for  the  critical  design  review  section  is  the  Aug  2008  Post- 
CDR  briefing  presented  by  the  PTPM  to  DT  management  following  the  CDR.) 
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XTR  Radar  Full  Power  Operation  (Summer  Condition)  -  All 
MDA  loads  fed  from  D/Gs  operating  In  Parallel.  SSTGs  supply 
all  Ship  Service  Loads. 


Figure  14.  One  line  diagram  of  the  power  generation  and  distribution  system 

presented  at  the  CDR 
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System 

Radar  On 
Max  kVA 

Radar  Off 
Max  kVA 

XTR-1 

Radar 

1,060 

- 

Technical 

145 

145 

Utility 

13 

13 

Total  XTR-1 

1,218 

158 

TTS-2 

Technical 

169 

169 

Utility 

144 

144 

Total  TTS-2 

313 

313 

Mission  Support 

Chilled  Water 

658 

434 

HVAC 

88 

88 

Diesel  Load 

104 

- 

Total  Mission  Support 

850 

522 

Grand  Total 

2,381 

993 

Table  8.  MARAD  ’s  load  analysis  results 


At  the  CDR,  it  was  clear  that  the  expected  loads  for  the  other  mission 
equipment  were  too  large  for  the  SSTGs  to  supply  when  the  radar  was  operating.  The 
SSTGs  could  supply  sufficient  power  to  the  other  mission  equipment  when  the  radar  was 
not  in  operation.  By  operating,  it  is  meant  that  generating  RF  energy  would  either  be 
transmitted  or  converted  into  heat  in  devices  known  as  dummy  loads.  The  cooling 
necessary  while  the  radar  is  operating  is  too  much  for  the  SSTGs  along  with  the  other 
mission  equipment.  When  the  radar  is  in  operation,  both  SSDGs  are  necessary  for  power. 
One  SSDG  is  required  to  power  the  radar  and  one  SSDG  is  required  to  power  the  other 
mission  equipment.  Now,  when  the  power  system  is  configured  for  radar  operation,  if 
the  SSDG  powering  the  radar  fails,  the  other  SSDG  must  shed  the  other  mission 
equipment  load  and  switch  to  power  the  radar.  The  other  mission  equipment  has  to  rely 
on  the  UPS  for  power.  In  a  similar  fashion,  when  the  power  system  is  configured  for 
radar  operation  and  if  the  SSDG  powering  the  other  mission  equipment  were  to  fail,  the 
other  mission  equipment  has  to  rely  on  the  UPS  for  power.  In  this  case,  the  other  SSDG 
would  continue  to  power  the  radar. 
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Two  other  significant  changes  were  made  to  the  power  system  design. 
The  size  of  the  UPSs  were  increased  and  the  utility  power  for  the  TTS  shelters  was 
moved  off  the  Mission  Support  UPS  and  over  to  the  SSTGs.  The  two  400  kVA  UPSs  in 
the  SRR  concept  had  to  be  increased  to  750  kVA  each.  The  maximum  load  on  the  clean 
power  UPS  was  expected  to  be  336  kVA  while  the  maximum  load  on  the  mission  support 
UPS  had  grown  to  745  k  VA.  The  predicted  load  on  the  clean  power  UPS  did  not 
increase  much  from  the  SRR.  The  predicted  load  on  the  mission  support  UPS  had  a 
significant  increase.  In  particular,  the  chilled  water  and  HVAC  were  the  biggest  factors 
which  drove  the  power  requirements.  Both  UPSs  did  not  have  to  increase  to  the  750 
kVA  size.  The  clean  UPS  could  have  easily  stayed  at  400  kVA.  However,  the  decision 
was  made  to  keep  the  UPSs  identical  with  the  expectation  of  reducing  the  cost  of  critical 
spares  that  must  be  kept  onboard  the  ship.  One  may  note  the  total  load  is  not  evenly 
spread  over  the  two  UPSs. 

The  load  is  not  more  evenly  split  because  of  the  type  of  loads.  The 
compressors  and  other  equipment  on  the  Mission  Support  UPS  are  considered  to  be  fairly 
noisy.  And,  that  equipment  does  not  require  clean  power  as  the  mission  electronics  will. 
The  Mission  Electronics  UPS  provides  power  conditioning  for  the  equipment  attached 
behind  it  from  equipment  attached  on  the  front  side.  It  protects  the  Mission  Electronics 
from  noisy  loads  such  as  the  radar’s  high  power  voltage  power  supplies  and  compressors. 
This  is  why  the  TTS  utility  power  was  not  shifted  over  to  the  Mission  Electronics  UPS 
even  though  there  is  more  than  enough  margin  left  on  the  Mission  Electronics  UPS  to 
accommodate  the  TTS  utility  power.  The  TTS  utility  power  was  shifted  off  the  Mission 
Support  UPS  because  the  predicted  load  on  that  UPS  had  grown  so  large.  The  load  on 
the  Mission  Support  UPS  provided  motivation  to  move  the  TTS  utility  power  off  that 
UPS  and  because  the  noisy  equipment  described  as  TTS  Utility  could  produce  problems 
for  the  equipment  powered  by  the  other  UPS.  Thus,  the  decision  was  made  to  instead 
shift  the  load  in  question  to  the  SSTGs. 

This  decision  avoided  the  need  to  go  to  an  even  larger  or  third,  smaller 
UPS.  The  decision  also,  however,  made  the  mission  equipment  more  dependent  on  the 
SSTGs.  Table  8  indicates  that  both  SSTGs  are  needed  to  fully  supply  utility  power  for 
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the  TTS  shelters.  This  leaves  the  TTS  Utility  equipment  without  an  instantaneous  souree 
of  baekup  power.  Not  providing  TTS  Utility  equipment  with  instantaneous  baekup  was 
judged  to  be  aeeeptable  for  several  reasons.  The  loss  of  HVAC  and  lighting  does  not 
instantaneously  stop  the  TTS  data  colleetion.  Depending  on  ambient  temperature 
conditions,  the  TTS  may  be  able  to  operate  30  minutes  without  HVAC.  Analysis  also 
indicated  that  the  ship’s  crew  would  be  able  to  shed  enough  of  the  ship’s  load  to  allow 
the  TTS  utility  equipment  to  come  back  on  line  prior  to  degradation  of  the  data 
collection.  Because  of  the  conservatism  in  calculating  the  predicted  load,  the  second 
SSTG  may  not  actually  be  needed. 

No  new  designs  for  the  crew  berthing  were  presented.  After  the  SRR, 
MARAD  evaluated  several  other  options  for  adding  additional  rooms.  None  of  the 
options  resulted  in  a  significant  cost  savings  over  what  had  been  considered  at  the  SRR. 
The  number  of  staterooms  for  the  MDA  mission  crew  did  not  change;  however,  it  was 
determined  that  three  of  the  rooms  that  had  been  counted  as  single,  because  of  how  they 
had  been  previously  used,  were  actually  double  staterooms.  Therefore,  the  allowable 
number  of  MDA  mission  personnel  increased  by  three  and  now  stood  at  27,  just  two  less 
than  the  stated  requirement  of  29. 

e.  Contract  Award 

The  work  package  in  the  bid  request  was  consistent  with  the  design  at 
CDR.  Only  one  bid  was  received.  Because  the  cost  of  the  bid  was  much  higher  than 
expected,  the  work  package  was  reduced  to  fit  into  available  funding.  Of  the  items 
discussed  in  this  thesis,  the  major  design  change  was  to  place  the  TTS  antennas  on  top  of 
the  hatch  coamings.  Several  months  after  the  shipyard  work  began,  additional  funding 
was  identified,  and  the  contract  was  modified  to  revert  to  the  TTS  placement  per  the  CDR 
design. 
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III.  REVIEW  OF  DODAF 


A.  INTRODUCTION 

This  chapter  discusses  the  Department  of  Defense  Architecture  Framework 
(DoDAF).  Except  as  otherwise  cited,  all  quotes  and  figures  in  this  chapter  are  taken  from 
the  DoD  Architecture  Framework  Version  1.5  Volume  I:  Definitions  and  Guidelines  23 
April  2007.  The  term  architecture  is  in  common  usage  usually  applies  to  the  structure  or 
appearance  of  a  building.  Because  architecture  is  applied  to  more  than  buildings,  it  is 
important  to  establish  what  is  meant  by  architecture.  Architecture,  in  this  paper,  is  the 
“structure  of  components,  their  relationships,  and  the  principles  and  guidelines  governing 
their  design  and  evolution  over  time”  (DoDAF  Version  1.5  v  I).  With  this  definition,  the 
architecture  still  applies  to  the  form  and  function  of  buildings  and  also  to  such  diverse 
entities  such  as  software,  organizations,  and  military  systems.  The  Defense  Science 
Board  has  determined  that  standardized  architecture  descriptions  are  vital  for  ensuring 
interoperable  and  cost  effective  military  systems  (USD(A&T),  ASD(C3I),  J6,  1997). 
“An  architecture  description  is  a  representation  of  a  defined  domain,  as  of  a  current  or 
future  point  in  time,  in  terms  of  its  component  parts,  how  those  parts  function,  the  rules 
and  constraints  under  which  those  parts  function,  and  how  those  parts  relate  to  each  other 
and  to  the  environment.”  (DoDAF  Version  1.5,  v  I) 

Interoperability  describes  how  well  entities  function  and  work  together.  More 
formally,  interoperability  is  defined  as  “The  ability  of  systems,  units,  or  forces  to  provide 
data,  information,  materiel,  and  services  to  and  accept  the  same  from  other  systems,  units, 
or  forces  and  to  use  the  data,  information,  material,  and  services  so  exchanged  to  enable 
them  to  operate  effectively  together”  (DAU  Glossary).  As  competition  for  resources  and 
complexity  of  systems  increases,  so  does  the  need  to  make  sure  all  of  the  pieces  function 
and  work  together.  The  probability  of  extraneous  or  poorly  integrated  components 
increases  with  the  system’s  complexity.  The  DoD  can  ill  afford  the  cost  of  inefficiencies 


41 


produced  by  extraneous  or  poorly  integrated  eomponents.  To  help  ensure  interoperable 
and  eost  effective  military  systems,  the  DoD  has  established  DoDAF  to  describe  DoD 
system  architeetures. 

The  DoDAF  is  an  evolution  of  the  1997  Command,  Control,  Communications, 
Computers,  Intelligenee,  Surveillance,  and  Reeonnaissance  (C4ISR)  Arehiteeture 
Framework.  The  DoDAF ’s  purpose  is  to  provide  guidance  for  describing  warfighting 
operations  and  business  operations  and  proeesses,  not  just  C4SIR  systems.  The  DoDAF 
does  not  provide  guidanee  on  how  to  construet  or  implement  a  speeific  architecture  or 
how  to  develop  and  aequire  systems.  The  framework  provides  rules,  guidance,  and 
produet  descriptions  for  developing  and  presenting  arehiteeture  deseriptions.  The 
prineipal  objeetive  of  the  framework  is  to  make  sure  arehiteeture  deseriptions  of  DoD 
systems  ean  be  related  and  compared  throughout  DoD,  across  service  and  even  multi¬ 
national  boundaries.  Common  principles,  assumptions,  and  terminology  address  this 
objective.  The  DoDAF  specifies  three  views  that  eombine  to  deseribe  the  architecture. 
The  three  are  Operational  View  (OV),  Systems  View  (SV),  and  Teehnieal  Standards 
View  (TV).  Figure  15  (DoDAF  Version  1)  illustrates  the  relationships  between  the  three 
views. 


All-View 


Figure  15.  Interrelationships  among  DoDAF  views 
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B.  OPERATIONAL  VIEW 

The  OV  is  a  description  of  the  mission,  warfighting,  and  other  entities  that  need  to 
be  supported  by  the  system.  It  describes  what  is  going  on  with  the  system  in  the  field. 
The  OV  contains  textual  and  graphical  products  that  identify  the  elements,  assigned 
operations,  and  information  flow  between  elements.  This  view  reveals  requirements  for 
capabilities  and  interoperability.  OV  descriptions  are  useful  for  DoD  wide  assessments 
to  examine  business  processes,  technology  insertion,  or  doctrinal  and  policy  implications, 
to  name  a  few. 

Usually  the  OV  of  a  system  is  doctrine-driven.  However,  outside  forces  can 
cause  a  system  or  organization  to  operate  in  a  manner  inconsistent  with  doctrine.  In  these 
cases,  the  OV  can  be  very  useful  to  determine  if  doctrine  changes  are  in  order  or  if  the 
root  cause  is  some  other  factor  such  as  lack  of  supporting  infrastructure  or  information. 
Ideally,  an  OV  is  independent  of  materiel.  However,  new  technologies  may  influence  or 
push  elements,  assigned  operations,  and  information  flow  between  elements.  For  this 
reason,  some  high-level  SV  products  or  data  elements  may  be  needed  to  support 
information  in  the  OV  products. 

C.  SYSTEMS  VIEW 

The  SV  describes  the  existing  and  future  systems  and  physical  interconnections 
that  support  the  mission  documented  in  the  OV.  As  used  in  DoDAF,  a  system  is  defined 
as  “any  organized  assembly  of  resources  and  procedures  united  and  regulated  by 
interaction  or  interdependence  to  accomplish  a  set  of  specific  functions”  (DoDAF 
Version  1.0).  The  SV  is  used  to  address  specific  systems.  This  can  include  current, 
developing,  or  conceptual  technologies,  depending  on  the  purpose  for  developing  the 
architecture.  The  level  of  detail  in  the  SV  will  depend  on  the  purpose  for  developing  the 
architecture.  Architectures  are  developed  for  a  variety  of  reasons.  DoDAF  users  may 
develop  Systems  Views  to  describe  the  system’s  current  state,  to  assist  in  transitioning  to 
a  new  state,  or  to  analyze  future  options. 
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D.  TECHNICAL  STANDARDS  VIEW 


The  DoDAF  defines  TV  as  the  smallest  set  of  rules  overarching  the  interaction, 
interdependence,  and  arrangement  of  system  parts  or  elements.  This  view  is  used  to 
ensure  that  a  system  meets  particular  operational  requirements.  The  TV  provides  the 
technical  guidelines  on  which  the  engineering  specifications  are  based,  products  are 
developed,  and  common  building  blocks  are  recognized.  This  view  additionally 
augments  the  SV  with  forecasts  of  standard  technology  evolution. 

E.  PRODUCTS 

The  DoDAF  also  defines  29  architecture  products,  which  are  organized  into  All 
Views,  OV,  SV,  and  TV.  Figure  16  provides  a  list  of  architecture  products  (DoDAF 
Version  1.5).  The  DoDAF  Version  1.5  also  provides  specific  guidance  on  which 
architecture  products  are  applicable  for  various  uses  of  architecture  descriptions.  This  is 
shown  in  Table  2  (DoDAF  Version  1.5). 
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Applicable 

View 

Framework 

Product 

Framework  Product  Name 

Net-Centric 

Extension 

General  Description 

All  View 

AV-1 

Overview  and  Summary  Information 

Scope,  purpose,  intended  users,  environment  depicted, 
analytical  findings 

Ail  View 

AV-2 

Integrated  Dictionary 

Architecture  data  repository  with  definitions  of  all  terms 
used  in  all  products 

Operational 

OV-1 

High-Level  Operational  Concept  Graphic 

V' 

High-level  graphical/textual  description  of  operational 
concept 

Operational 

OV-2 

Operational  Node  Connectivity 

Description 

Operational  nodes,  connectivity,  and  information 
exchange  need  lines  between  nodes 

Operational 

OV-3 

Operational  Information  Exchange  Matrix 

Information  exchanged  between  nodes  and  the  relevant 
attributes  of  that  exchange 

Operational 

OV-4 

Organizational  Relationships  Chart 

Organizational,  role,  or  other  relationships  among 
organizations 

Operational 

OV-5 

Operational  Activity  Model 

Capabilities,  operational  activities,  relationships  among 
activities,  inputs,  and  outputs;  overlays  can  show  cost, 
performing  nodes,  or  other  pertinent  information 

Operational 

0V-6a 

Operational  Rules  Model 

One  of  three  products  used  to  describe  operational 
activity— identifies  business  rules  that  constrain 
operation 

Operational 

OV-6b 

Operational  State  Transition  Description 

One  of  three  products  used  to  describe  operational 
activity— identifies  business  process  responses  to 
events 

Operational 

0V-6C 

Operational  Event-Trace  Description 

One  of  three  products  used  to  describe  operational 
activity— traces  actions  in  a  scenario  or  sequence  of 
events 

Operational 

OV-7 

Logical  Data  Model 

Documentation  of  the  system  data  requirements  and 
structural  business  process  rules  of  the  Operational 

View 

Systems 

and 

Services 

SV-1 

Systems  Interface  Description 

Services  Interface  Description 

Identification  of  systems  nodes,  systems,  system  items, 
services,  and  service  items  and  their  interconnections, 
within  and  between  nodes 

Systems 

and 

Services 

SV-2 

Systems  Communications  Description 
Services  Communications  Description 

Systems  nodes,  systems,  system  items,  services,  and 
service  items  and  their  related  communications  lay- 
downs 

Systems 

and 

Services 

SV-3 

Systems-Systems  Matrix 

Services-Systems  Matrix 

Services-Services  Matrix 

Relationships  among  systems  and  services  in  a  given 
architecture;  can  be  designed  to  show  relationships  of 
interest,  e  g.,  system-type  interfaces,  planned  vs. 
existing  interfaces,  etc. 

Systems 

and 

Services 

SV-4a 

Systems  Functionality  Description 

Functions  performed  by  systems  and  the  system  data 
flows  among  system  functions 

Systems 

and 

Services 

SV-4b 

Services  Functionality  Description 

Functions  performed  by  services  and  the  service  data 
flow  among  service  functions 

Systems 

and 

Services 

SV-5a 

Operational  Activity  to  Systems  Function 
Traceability  Matrix 

Mapping  of  system  functions  back  to  operational 
activities 

Systems 

and 

Services 

SV-5b 

Operational  Activity  to  Systems 

Traceability  Matrix 

Mapping  of  systems  back  to  capabilities  or  operational 
activities 

Systems 

and 

Services 

SV-5C 

Operational  Activity  to  Services 

Traceability  Matrix 

Mapping  of  services  back  to  operational  activities 

Systems 

and 

Services 

SV-6 

Systems  Data  Exchange  Matrix 

Services  Data  Exchange  Matrix 

Provides  details  of  system  or  service  data  elements 
being  exchanged  between  systems  or  services  and  the 
attributes  of  that  exchange 
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Applicable 

View 

Framework 

Product 

Framework  Product  Name 

Net-Centric 

Extension 

General  Description 

Systems 

and 

Services 

SV-7 

Systems  Performance  Parameters  Matrix 
Services  Performance  Parameters  Matrix 

Performance  characteristics  of  Systems  and  Services 
View  elements  for  the  appropriate  time  frame(s) 

Systems 

and 

Services 

SV-8 

Systems  Evolution  Description 

Services  Evolution  Description 

Planned  incremental  steps  toward  migrating  a  suite  of 
systems  or  services  to  a  more  efficient  suite,  or  toward 
evolving  a  current  system  to  a  future  implementation 

Systems 

and 

Services 

SV-9 

Systems  Technology  Forecast 

Services  Technology  Forecast 

Emerging  technologies  and  software/hardware  products 
that  are  expected  to  be  available  in  a  given  set  of  time 
frames  and  that  will  affect  future  development  of  the 
architecture 

Systems 

and 

Services 

SV-10a 

Systems  Rules  Model 

Services  Rules  Model 

One  of  three  products  used  to  describe  system  and 
service  functionality— identifies  constraints  that  are 
imposed  on  systems/services  functionality  due  to  some 
aspect  of  systems  design  or  implementation 

Systems 

and 

Services 

SV-10b 

Systems  State  Transition  Description 
Services  State  Transition  Description 

One  of  three  products  used  to  describe  system  and 
service  functionality— identifies  responses  of  a 
system/service  to  events 

Systems 

and 

Services 

SV-10C 

Systems  Event-Trace  Description 

Services  Event-Trace  Description 

One  of  three  products  used  to  describe  system  or 
service  functionality— identifies  system/service-specific 
refinements  of  critical  sequences  of  events  described  in 
the  Operational  View 

Systems 

and 

Services 

SV-11 

Physical  Schema 

Physical  implementation  of  the  Logical  Data  Model 
entities,  e  g.,  message  formats,  file  structures,  physical 
schema 

TV-1 

Technical  Standards  Profile 

Listing  of  standards  that  apply  to  Systems  and  Services 
View  elements  in  a  given  architecture 

TV-2 

Technical  Standards  Forecast 

Description  of  emerging  standards  and  potential  impact 
on  current  Systems  and  Services  View  elements,  within 
a  set  of  time  frames 

Figure  16.  DoDAF  Products 
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Applicable  Architecture  Product  Data 
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Figure  17.  Architecture  Products  and  their  Applicability 


F.  DODAF  SUMMARY 

Architecture  is  the  “structure  of  components,  their  relationships,  and  the 

principles  and  guidelines  governing  their  design  and  evolution  over  time.”  An 

architecture  description  is  a  representation  of  a  defined  domain,  as  of  a  current  or  future 

point  in  time,  in  terms  of  its  component  parts,  how  those  parts  function,  the  rules  and 

constraints  under  which  those  parts  function,  and  how  those  parts  relate  to  each  other  and 

to  the  environment.”  To  help  ensure  interoperable  and  cost  effective  military  systems, 

the  DoD  has  established  DoDAF  to  describe  DoD  system  architectures.  The  DoDAF  is 

an  evolution  of  the  1997  (C41SR)  Architecture  Framework.  The  framework  provides 

rules,  guidance,  and  product  descriptions  for  developing  and  presenting  architecture 

descriptions.  The  DoDAF  specifies  three  views  that  combine  to  describe  the  architecture. 

The  three  views  are:  Operational  View  (OV),  Systems  View  (SV),  and  Technical 

Standards  View  (TV).  Usually  the  OV  of  a  system  is  doctrine-driven.  The  SV  is  used  to 
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address  specific  systems.  Architectures  are  developed  for  a  variety  of  reasons.  DoDAF 
users  may  develop  Systems  Views  to  describe  the  system’s  current  state,  to  assist  in 
transitioning  to  a  new  state,  or  to  analyze  future  options.  The  DoDAF  defines  TV  as  the 
smallest  set  of  rules  overarching  the  interaction,  interdependence,  and  arrangement  of 
system  parts  or  elements.  The  DoDAF  also  defines  29  architecture  products,  which  are 
organized  into  All  Views,  OV,  SV,  and  TV.  It  is  intended  to  allow  architecture 
descriptions  of  DoD  systems  to  be  related  and  compared  throughout  DoD,  across  service 
and  even  multi-national  boundaries. 
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IV.  ANALYSIS  OF  THE  APPLICABILITY  OF  DODAF  TO  THE 
PACIFIC  TRACKER  CONVERSION 


A.  INTRODUCTION 

In  this  chapter,  the  utility  of  applying  DoDAF  to  the  PT  program  is  analyzed.  An 
architecture  for  the  PT  is  described,  and  the  possible  impact  of  the  architecture  on  the 
course  of  the  program  is  considered.  The  purpose  of  the  PT  is  to  fill  radar  gaps  in  a  wide 
variety  of  MDA  flight  tests  across  the  Pacific.  The  effort  to  convert  a  ship  to  host  an 
instrumentation  radar  and  telemetry  system  was  conducted  without  the  use  of  DoDAF.  In 
this  chapter,  an  architecture  that  could  have  been  produced  and  utilized  to  support  the 
conversion  effort  is  described.  The  PT  architecture  consists  of  nine  DoDAF  data 
products.  The  data  products  are  as  follows:  AV-1,  OV-1-5,  SV-1,  2,  and  6.  Each  of  these 
data  products  is  subjectively  assessed  for  possible  impacts  on  the  program’s  course. 

B.  SELECTED  BEA  VER  STA TE  CONVERSION  DODAF  PRODUCTS 

1.  All  View-1  Overview  and  Summary  Information 

AV-1  is  a  text  document  used  to  provide  information:  1)  to  identify  the  project;  2) 
the  scope  of  the  architecture;  3)  its  purpose  and  viewpoint;  4)  its  context,  and  5)  the  tools 
and  file  formats  used.  AV-1  for  the  conversion  is  provided  as  a  PowerPoint  slide  in 
Figure  18. 
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AV-1  Overview  and  Summary  Information 


•  Architecture  Project  Identification 

Name:  Beaver  State  conversion  to  Pacific  Tracker 

-  Architect:  Mike  Lash 

-  Organization  Deveioping  the  Architecture:  MDA/DTR  Sea  Based  Piatforms 

-  Approvai  Authority:  TBD 

-  Date  Compieted:  Version  1.119  May  2009 

Levei  of  Effort  and  Projected  Costs  to  Deveiop  the  Architecture:  200  hours 

•  Scope:  Architecture  View(s)  and  Products  Identification 

-  Views  and  Products  Deveioped:  AV  1;  OV  1-5,  SV  1-2,  6 

-  Time  Frames  Addressed:  Current  and  End  State 

-  Organizations  invoived:  MDA/DTR,  MARAD  HQ,  MARAD  Western  Region,  MiT/LL,  WSMR,  MDO, 
JHU/APL,  interocean  American  Shipping  (iAS),  NAVAIR,  NSWC-Corona 

•  Purpose  and  Viewpoint 

-  Purpose,  Analysis,  Questions  to  be  Answered  by  analysis  of  the  Architecture: 

-  Assess  whether  incorporating  DoDAF  would  have  improved  the  way  the  project  was  done. 

-  What  DoDAF  products  might  have  been  produced  to  support  the  project? 

-  How  may  have  the  DoDAF  methodology  changed  the  way  the  project  was  done? 

-  Would  the  DoDAF  methodology  have  been  useful  to  the  project  or  be  useful  to  future  MDAtest  asset 
development  projects? 

From  Whose  Viewpoint  the  Architecture  is  Developed:  Program  Manager/  Systems  Engineer 

•  Context 

Mission:  Conversion  of  Beaver  State  to  HostXTR-1  and  TTS-2 

Doctrine,  Goals,  Vision:  Produce  a  cost  effective  range  instrumentation  ship  which  will  reduce  BMDS 
dependence  on  land  based  radars 

Rules,  Criteria,  and  Conventions  Followed:  Must  be  compatible  with  other  range  assets 

-  Tasking  for  Architecture  Project  and  Linkages  to  Other  Architectures:  None 

•  Tools  and  File  Formats  Used:  Microsoft  Office  2003 


Figure  18.  Pacific  Tracker  Overview  and  Summary  Information 


2.  OV-1  High  Level  Concept  Description 

OV-1  provides  a  graphical  high  level  description  of  the  concept.  As  shown  in 
Figure  19,  the  Pacific  Tracker  is  designed  to:  collect  and  record  X  &  S  band  radar  data 
and  S  band  telemetry  data  on  BMDS  flight  test  events;  send  and  receive  data  via 
SATCOM  to  and  from  other  test  participations;  and  to  operate  in  the  BOA.  The  graphic 
shows  the  XTR-1  antenna  mounted  behind  the  house  and  the  twin  TTS-2  antennas 
mounted  in  front  of  the  house.  The  graphic  depicts  the  two  sensors  collecting  data  on  an 
interceptor  and  target  missile.  Also,  as  depicted  other  test  participants  may  be  other  sea 
base  systems,  airborne  sensors,  and  land-based  systems. 
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OV-1  High  Level  Concept  Description 


•  The  Pacific  Tracker  is  designed  to 

-  Collect  and  record  X  &  S  band  radar  and  S  band  TM  on  BMDS  flight  test 
events 

-  Send/receive  data  real  time  via  SATCOM  to/from  other  test  participants 

-  Operate  from  the  broad  ocean  area  (BOA) 


Figure  19.  Pacific  Tracker  High  Level  Concept  Description 


3.  OV-2  Operational  Node  Connectivity 

OV-2,  in  Figure  20,  provides  a  description  of  the  operational  node  connectivity. 
A  drawing  of  the  physical  system  passing  data  to  actors  who  are  part  of  the  test  event  is 
used.  It  seems  that  using  such  a  drawing  is  a  poor  practice.  The  drawing  can  add  to  the 
confusion  caused  by  having  a  physical  system,  the  ship,  the  XTR-1,  and  TTS-2,  called 
the  Pacific  Tracker;  a  project  named  Pacific  Tracker;  and  a  ship  named  Pacific  Tracker. 
In  the  early  phases  of  a  test  event,  the  physical  system  is  not  being  used  to  exchange 
information  with  the  Test  Resource  Manager  (TRM).  Test  planners  with  the  Pacific 
Tracker  program  will  be  exchanging  information  with  the  TRM  by  standard  methods  of 
business  communications,  for  example,  email  and  phone  conversations. 


51 


The  upper  part  of  Figure  20  is  taken  from  MDA  Direetive  3002.03  dated  15 
January  2009.  It  shows  the  five  phases  of  a  BMDS  test  event:  1)  Requirements,  2) 
Planning  and  Design,  3)  Readiness,  4)  Exeeution,  and  5)  Analysis  and  Reporting.  In  the 
first  three  phases  and  the  first  part  of  the  fourth  phase,  the  information  flowing  through 
the  TRM  to  the  Paeifie  Tracker  program  is  data  requirements,  test  event  description,  and 
status.  Questions  about  capabilities  and  status  will  also  flow  to  the  PT  program.  Often, 
capability  questions  will  start  with  “Can  you...”  or  “What  if...”  The  information  that 
will  be  exchanged  between  the  Pacific  Tracker  program  and  the  test  event  via  the  TRM 
will  tend  to  become  more  detailed  as  time  progresses.  The  initial  information  will  start 
with  general  information  about  data  requirements  and  general  information  on  the  what, 
where,  and  when  of  the  test  scenario.  As  the  level  of  detail  of  the  data  collection 
requirements  and  scenario  information  increases,  so  too  will  the  level  of  detail  in  the 
plans  the  PT  program  provides  back  to  the  test  event  via  the  TRM.  During  the  first  three 
phases  and  the  first  part  of  the  fourth  phase,  the  PT  system  will  not  be  used  to  support  the 
test  event. 
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OV-2  Operational  Node  Connectivity 
Description 


BMDS  TEST  EVENT 


MurplidEvHl 


||&T|]ripiii 

D  iinii] 


I  Count  Status 

Pointing  Data 


Flight 

Test  Event 


•  BMDS  Test  Events  progress  from  start  to  completion  through  the 
five  phases 

•  The  PT  program  supports  BMDS  Test  Event  through  ail  five  phases 

•  The  PT  system  supports  the  Execution  phase 


Figure  20.  OV-2  Operational  Node  Connectivity  Description 


For  the  design  of  the  PT  system,  the  node  connectivity  of  the  earlier  phases  is  not 
as  important  as  the  node  connectivity  when  the  PT  system  is  used.  Current  planning  calls 
for  the  Pacific  Tracker  system  to  begin  supporting  a  test  event  towards  the  later  part  of 
the  fourth  phase,  Execution.  A  dockside  communications  demonstration  is  expected  to 
be  generally  the  first  time  the  system  will  be  used  to  support  a  given  test.  Then, 
sometime  after  the  communications  demonstration,  the  system  will  be  put  to  sea. 
However,  depending  upon  the  distance  between  test  support  positions  and  the  time 
between  test  events,  the  system  may  already  be  at  sea  during  the  first  communications 
demonstration.  The  communications  demonstration  not  only  demonstrates  that  the 
communications  links  for  the  live  flight  test  are  operational;  it  also  demonstrates  the 
participant  systems’  ability  to  process  simulated  data. 
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The  live  flight  test  is  depicted  by  the  maroon  star  in  Figure  20  labeled  “Test 
Event.”  For  purposes  of  this  thesis,  the  live  flight  test  is  the  time  that  the  missiles  are  in 
flight.  During  the  live  flight  test,  test  data  and  voice  communications  will  be  exchanged 
between  the  test  event  via  the  range  and  the  PT  program  using  the  PT  system  in  real  time. 
Figures  21  and  22  depict  the  node  connectivity  for  test  data  and  for  voice  communication, 
respectively.  Figure  21  is  the  OV-2  that  depicts  the  operational  node  connectivity  for 
digital  data  passed  between  the  electronic  systems.  Figure  22  is  the  OV-2  that  depicts  the 
operational  node  connectivity  for  voice  communications. 

Figure  21  shows  connectivity  between  the  range  and  the  two  sensors,  XTR-1  and 
TTS-2.  There  is  also  connectivity  between  the  sensors  and  the  Pacific  Tracker  Lead 
(PTL)  Situational  Awareness  Display  (SAD).  The  type  of  information  sent  from  the 
range  to  the  sensors  is  the  countdown  clock  and  track  data  on  selected  test  objects.  Track 
data  on  the  objects  being  tracked  by  the  sensors  are  sent  to  each  other  and  the  range. 
Other  selected  data  collected  by  the  sensors  are  also  sent  to  the  range.  The  sensors  will 
also  send  track  data  to  the  PTL  SAD  along  with  other  real  time  data  to  keep  the  PTL 
advised  of  the  sensors’  respective  status. 
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Figure  2 1 .  OV-2  Operational  Node  Connectivity  Description  Test  Event  Data 


In  addition  to  digital  data  passed  between  electronic  systems,  verbal 
communications  will  occur  between  individuals  participating  in  the  mission.  Figure  22  is 
the  OV-2  description  for  the  verbal  node  connectivity  during  the  test  event.  There  will  be 
other  voice  nets  onboard  and  off  board  than  what  is  shown  in  Figure  22.  Figure  22  shows 
the  primary  voice  nets.  The  intent  is  to  have  the  PTL  be  the  primary  human  interface 
with  the  range  officer.  One  reason  to  do  this  is  to  reduce  the  task  loading  on  the 
respective  sensor  leads.  It  is  also  intended  that  only  one  person,  the  PTL,  is  providing 
direction,  requests,  and  questions  to  the  ship’s  master. 
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Figure  22.  OV-2  Operational  Node  Connectivity  Description  Test  Event  Voice 

4  OV-3  Operational  Information  Exchange  Matrix 

OV-3  is  a  tabular  representation  of  operational  information  exchange  along  the 
need  lines  as  depicted  in  OV-2.  Figures  23  and  24  present  more  detailed  listings  of 
information  exchanged  between  nodes  and  some  information  on  what  the  receiving  node 
does  with  the  information.  The  format  for  Figures  23  and  24  was  taken  from  Maj  Hartt’s 
executive  seminar  on  DoDAF  (n.d.).  DoDAF  1.5  volume  II  provides  an  OV-3  template 
which  allows  for  more  details  to  be  provided  in  the  matrix.  However,  Maj  Hartt’s 
template  addresses  the  key  needs  associated  with  the  PT  system  (DoD  Architecture 
Framework  Executive  Seminar,  n.d.). 
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OV-3  Operational  Information  Exchange  Matrix 
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Figure  23. 


OV-3  Operational  Information  Exchange  Matrix  with  Test  Event  Data 


57 


OV-3  Operational  Information  Exchange  Matrix 
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Figure  24.  OV-3  Operational  Information  Exchange  Matrix  with  Test  Event  Voice 

5  OV-4  Organizational  Relationships 

If  DoDAF  had  been  used,  it  is  likely  that  the  current  and  end  state  organizational 
relationships  would  have  been  considered.  The  organizational  relations  evolved  over  the 
course  of  the  program.  To  keep  the  architecture  description  current,  OV-4  may  have 
been  updated  from  time  to  time.  Here,  OV-4  is  produced  relative  to  two  junctures  in  the 
program:  the  ASP  and  the  shipyard  contract  award.  Figure  25  shows  the  organizational 
relationships  at  the  time  of  the  ASP.  Figure  26  shows  the  relationships  at  the  time  of  the 
contract  award.  OV-4  descriptions  are  also  produced  for  possible  end  state 
configurations.  Figure  27  reflects  possible  overall  program  relationships,  and  Figure  28 
shows  possible  relationships  during  flight  test  operations  on  the  ship. 
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Figure  25  shows  the  relationships  between  the  three  branches,  also  called  product 
offices,  within  the  Test  Resource  Infrastructure  Division  (DTRl)  involved  with  the 
Pacific  Tracker  program.  Flight  Safety  and  Telemetry,  Sea-Based  Platforms,  and  the 
Radar  Development  Branches.  At  the  time  of  the  ASP,  the  TM  and  Flight  Safety  branch 
had  already  developed  TTS-1  &  2.  This  branch  also  oversaw  the  TTS-1  operations  on 
the  Pacific  Collector  and  TTS-2  operations  on  land.  The  TTS  was  developed  and 
operated  by  a  group  from  WSMR.  WSMR  had  selected  NSWC-Corona  to  develop  and 
operate  its  SATCOM  system.  The  SBP  Branch  was  charged  with  the  responsibility  to 
select  and  modify  a  ship  to  meet  XTR-1  requirements.  MARAD  was  the  executing  agent 
for  SBS.  MARAD  Western  Region,  at  the  direction  of  MARAD  HQ,  engaged  a  firm,  ICl 
and  its  sub  contractor  MDO,  to  perform  the  naval  architecting.  MIT/LL  was  still  in  the 
process  of  developing  the  XTR-1  for  the  RD  Branch.  The  RD  arranged  for  the  targets 
group  from  NAVAIR,  Naval  Air  Station,  Pawtuxet  River  to  be  the  EA  for  the  radar 
operation  through  its  contractor  Computer  Sciences  Corporation  (CSC).  It  was  planned 
for  CSC  to  provide  the  permanent  crew  for  the  XTR-1.  The  RD  branch  also  went  to 
NSWC  Corona  group  to  develop  and  operate  the  STACOM  system.  At  the  time  of  the 
ASP,  the  three  branches  were  organizationally  on  the  same  hierarchical  level;  however, 
SBP  was  tasked  to  accommodate  RD/XTR-1  requirements  and  soon  after  the  ASP, 
TM&Safety/TTS  requirements  were  added  to  the  tasking. 
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OV-4  Organizational  Relationships 
Development 
rASP  Aug  2007^ 


Figure  25.  OV-4  Organizational  Relationships  August  2007 

By  the  time  of  the  shipyard  contract  award,  the  hierarchy  among  the  DTRI 
branches  had  changed.  Figure  26  reflects  the  organization  at  the  time  of  the  shipyard 
contract  award.  Most  of  the  organizations  were  still  involved;  however,  there  were 
several  significant  changes.  The  TM/Safety  Office  was  brought  within  SBP  so  that  the 
vessels  and  on  board  instrumentation  would  have  common  management  within  DTRI. 
SBP  also  took  over  responsibility  for  the  communications  system  and  brought  the  Corona 
group  within  the  SBP  purview.  MARAD  was  able  to  reduce  one  contract  by  moving  the 
Naval  Architects  subcontract  under  IAS.  By  the  time  the  contract  was  awarded,  SBP  was 
also  assigned  the  lead  systems  engineering  role  for  the  Pacific  Tracker  program,  a 
significantly  different  role  than  modifying  a  ship  to  meet  XTR-1  requirements. 
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OV-4  Organizational  Relationships 
Development 

(Shipyard  contract  award  Jan  2007^ 


Figure  26.  OV-4  Organizational  Relationships  January  2009 

Once  XTR-1  development  is  completed,  current  plans  call  for  responsibility  for 
XTR-1  to  be  brought  within  SBP,  just  as  the  TM/Safety  Office  was  brought  within  SBP 
so  that  the  vessels  and  on  board  instrumentation  would  have  common  management  within 
DTRI.  As  shown  in  Figure  27,  a  possible  end  state  is  for  the  SBP  office  to  be  relative  to 
only  the  Pacific  Tracker  program.  Organizational  relationships  are  not  shown  for  the 
other  systems:  Pacific  Collector,  KMRSS/Worthy,  and  the  MLP,  within  SBP.  Figure  27 
also  shows  how  SBP  will  have  to  interface  directly  with  at  least  five  different 
organizations  in  order  to  manage  the  Pacific  Tracker  program. 
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OV-4  Organizational  Reiationships 
Possibie  End  State  Pacific  Tracker 


Figure  27.  OV-4  Organizational  Relationships,  Possible  End  State  Pacific  Tracker 

As  part  of  the  management  of  the  Pacific  Tracker  program,  the  organization 
relationships  onboard  Pacific  Tracker  when  at  sea  also  needs  to  be  considered.  Figure  28 
shows  a  possible  configuration  for  the  system  at  sea.  While  MARAD  and  NAVAIR  will 
not  disappear  while  Pacific  Tracker  is  at  sea,  their  roles  will  become  more  indirect,  very 
much  like  SBP.  It  is  not  that  the  structure  shown  in  Figure  27  goes  away.  It  is  that  only  a 
subset  of  the  actors  relative  to  the  overall  program  goes  to  sea.  The  PTL  will  have  more 
direct  contact  with  the  Range  than  she  will  have  with  the  SBP.  The  thought  behind 
Figure  28  is  that  the  PTL  will  be  responsible  for  top  level  direction  and  coordination  of 
the  XTRL,  TTSL,  communications,  and  the  ship.  To  this  end,  the  PTL  is  in  the 
leadership  position  over  the  Pacific  Tracker  system  and  people  deployed  for  the  flight 
test.  The  ship’s  master  is  shown  in  a  subordinate  role  to  the  PTL  in  relation  to  flight  test 
support.  The  intent  is  to  reflect  the  overall  mission  of  flight  test  support.  The  master  has 
supremacy  in  matters  related  to  Safety  of  Life  at  Sea  (SOLAS)  and  the  safety  of  Pacific 
Tracker. 
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OV-4  Organizational  Relationships 
Possible  End  State  Pacific  Tracker 
fFliaht  Test  Operations^ 


Figure  28.  OV-4  Organizational  Relationships,  Possible  End  State  Pacific  Tracker 

(Flight  Test  Operations) 


6  OV-5  Operational  Activity  Model 

The  next  view  is  OV-5,  Operational  Activity  Model.  The  model  shown  in  Figure 
29  closely  matches  the  example  in  Maj  Hartt’s  DoDAF  executive  seminar  presentation 
(n.d.).  In  his  example,  Maj  Hartt  was  using  an  aerospace  operations  center  (AOC)  as  an 
example.  On  first  consideration,  a  missile  range  instrumentation  ship  does  not  resemble 
an  AOC  in  form  or  function.  However,  in  terms  of  the  process,  there  is  much  overlap. 
Both  the  AOC  and  test  assets  can  go  through  a  planning  -  execution  -  maintenance  cycle. 
The  first  step  is  to  obtain  information  necessary  for  planning.  Two  general  types  of 
information  entering  the  program  are  shown  at  the  top  left:  Requirements  and  Test  Event 
Information. 
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The  requirements  are  listed  first.  The  second  type  of  information  is  test  event 
related  information.  Requirements  may  be  data  collection  requirements  or  regulatory 
requirements.  Data  collection  requirements  will,  in  part,  describe  what  data  will  be 
collected  on  which  test  objects,  for  example.  Regulatory  requirements  are  laws,  licenses, 
and  restrictions  applicable  to  any  part  of  the  Pacific  Tracker  operation.  Test  information 
is  any  information  that  may  affect  planning.  Test  information  may  or  may  not  be  directly 
related  to  the  flight  test.  For  example,  information  on  launch  windows  is  directly  related 
to  the  test.  Weather  information,  while  not  directly  related  to  the  test,  can  certainly  affect 
data  collection  plans. 

The  BMDS  test  support  planning  group  will  take  this  information  and  produce  a 
plan  for  the  BMDS  test  execution  group  to  utilize  in  order  to  conduct  the  mission.  The 
planning  group  will  also  pass  along  other  relevant  information  to  the  test  support.  The 
execution  cell  will  support  the  test  in  accordance  to  the  accepted  plan.  The  execution 
group  will  provide  reports  and  data  outside  of  the  PT.  That  group  will  also  provide 
information  to  the  maintenance  group  on  the  performance  of  the  various  systems.  The 
maintenance  group  will  provide  information  on  the  condition  of  the  PT.  This  generic 
scenario  can  be  applied  to  TTS,  the  radar,  and  even  the  ship.  It  has  been  my  experience, 
depending  on  the  level  of  specialization  required,  that  the  individual  may  find  herself 
operating  in  one  or  more  of  the  identified  groups. 
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Another  example  of  an  operational  activity  model  is  shown.  Figure  30  illustrates 
some  of  the  activities  associated  with  execution  during  the  actual  test  event.  The  time 
period  covered  in  this  mode  may  range  between  5  hours  to  36  hours.  The  starting  event 
is  the  start  of  the  count  and  the  receipt  of  the  quick  look  report  is  used  as  the  terminating 
event.  The  systems  leads  will  ready  their  respective  systems  and  provide  reports  to  the 
PTL.  The  PTL  will  in  turn  provide  these  status  reports  to  the  range  on  a  predetermined 
schedule  that  is  usually  called  out  in  the  script  for  the  count  down  activities.  Depending 
on  the  status  of  the  various  test  participations,  the  range  will  have  a  decision  to  make  on 
adjusting  the  count  or  proceeding  as  scheduled.  The  launch  begins  the  data  flow  to  the 
PT  and  other  systems  involved  with  the  flight  test.  Pointing  information  in  the  form  of 
inter  range  state  vectors  will  flow  to  the  radar  and  TM  systems.  The  instrumentation 
leads  with  then  attempt  to  establish  track  on  their  respective  items  of  interest  as 
established  by  the  data  collection  plan.  Once  the  systems  are  in  track  and  collecting  data, 
the  systems  will  flow  pointing  information  to  each  other  and  back  to  the  range.  The 
activity  of  collecting,  recording,  flowing  data  will  continue  until  loss  of  signal  (LOS). 
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After  the  data  eollection  has  ended,  the  exeeution  team  will  produee  a  quick  look,  or 
multiple  quick  look  reports.  Reporting  times  can  vary  from  program  to  program.  The 
initial  report,  usually  provided  within  an  hour,  is  a  qualitative  assessment  of  how  the 
system  performed.  Specific  data  products  are  requested  to  support  the  Quick  Look 
Report,  which  is  generally  due  within  the  first  24  to  48  hours. 


OV-5  Operational  Activity  Model 

(Execution) 


■►{Data  Flow)  - ►{Activity  Flow) 


Figure  30.  OV-5  Operational  Activity  during  test  execution 

7  SV-1  System  Interface  Description 

OV-2  provided  a  description  of  nodes  or  parts  of  the  system  that  are  connected  to 
other  parts  of  the  system.  SV-1  System  Interface  Description  is  found  in  Figure  31.  It 
depicts  two  types  of  interfaces,  voice  and  data.  Voice  interfaces  are  used  between 
persons  on  Pacific  Tracker  and  person(s)  on  the  range.  It  also  indicates  data  interfaces 
between  systems  on  Pacific  Tracker  and  the  range.  As  shown  in  Figure  31,  the  XTRL, 
the  TTSL,  and  the  PTL  will  have  voice  communications  amongst  themselves  and  the 
range.  In  addition,  the  ship’s  master  will  have  voice  communications  with  the  PTL.  The 
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XTR-1,  TTS,  and  the  range  will  be  connected  in  such  a  manner  as  to  allow  the 
transmission  and  receipt  of  data  to  and  from  each  other.  The  PTL  Situational  Awareness 
display  is  able  to  receive  data  from  XTR-1,  TTS,  and  the  range. 


SV-1  System  Interface  Description  (Test  Event) 


Figure  31.  SV-1  System  Interface  Description 

8.  SV-2  Systems  and  Services  Communications  Description  and  SV-6 
Systems  Services  Data  Exchange  Matrix 

In  Figure  32,  SV-2,  a  different  graphical  depiction  is  used  to  provide  more 

detailed  information  on  the  communications  systems  used  to  connect  people  and  systems. 

Figure  32  in  and  of  itself  does  not  provide  much  additional  data  over  what  was  depicted 

in  SV-1,  Figure  31.  The  SV-2  produced  must  be  coupled  with  SV-6,  Figure  33,  to  get 

more  detailed  information  on  the  communications  services.  The  SV-6  matrix  contains 

information  on  the  medium,  bandwidth,  and  data  format.  Both  of  these  products  are 

capable  of  showing  more  information  on  the  communications  system  than  what  is 

presented  in  this  thesis.  These  products  were  intentionally  left  underdeveloped  for 

reasons  that  will  be  discussed  in  the  next  section  of  this  chapter. 
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SV-6  System  Services  Data  Exchange  Matrix 


Sender 

Receiver 

Content 

Media 

Bandwidth 

SV-2  Link 

PTL 

TTSL 

Request  Status 

VOIP 

L 

5 

PTL 

Ship  Master 

Request  Status 

VOIP 

L 

1 

PTL 

RP 

Provide  Status 

VOIP 

L 

2 

PTL 

XTRL 

Request  Status 

VOIP 

L 

4 

XTRL 

PTL 

Provide  Status 

VOIP 

L 

4 

XTRL 

RP 

Provide  Status 

VOIP 

L 

3 

XTR-1 

RS 

RADAR  Data 

IP  Network 

L 

7 

XTR-1 

TTS 

IRV 

IP  Network 

L 

16 

XTR-1 

PTL  SA 

IRV 

IP  Network 

L 

12 

XTR-1 

PTL  SA 

RADAR  Data 

IP  Network 

L 

8 

TTSL 

PTL 

Provide  Status 

VOIP 

L 

5 

TTSL 

RP 

Provide  Status 

VOIP 

L 

6 

TTS 

RS 

TM  Data 

IP  Network 

H 

10 

TTS 

RS 

IRV 

IP  Network 

L 

14 

TTS 

XTR-1 

IRV 

IP  Network 

L 

16 

TTS 

PTL  SA 

IRV 

IP  Network 

L 

13 

TTS 

PTL  SA 

TM  Data 

IP  Network 

H 

9 

XTR-1 

RS 

IRV 

IP  Network 

L 

11 

RP 

PTL 

Request  Status 

VOIP 

L 

2 

RP 

XTRL 

Request  Status 

VOIP 

L 

3 

RP 

TTSL 

Request  Status 

VOIP 

L 

6 

Figure  33.  SV-6  Services  Exchange  Matrix 


C  CONCLUSIONS:  POSSIBLE  IMPACT  OF  DODAF  ON  THE  PACIFIC 

TRACKER  PROGRAM 

In  my  estimation,  on  the  whole,  had  DoDAF  been  used,  there  might  have  been 
improvements  to  the  program.  However,  these  improvements  would  have  been  marginal. 
None  would  have  significantly  changed  the  course  of  the  effort,  though  at  times  some  of 
the  products  could  have  been  useful.  In  particular,  the  operational  views  seemed  to  have 
the  most  potential  utility.  The  system  views  appear  as  if  they  would  have  provided  very 
little  utility.  If  one  considers  the  reasons  for  using  DoDAF,  one  could  have  predicted  its 
limited  usefulness  to  the  Pacific  Tracker  project. 

Chapter  II  provided  a  description  of  some  other  ship  systems  used  in  missile 
defense  testing  and  a  description  of  the  design  evolution  major  modifications  to  the  ship. 
The  description  of  the  other  ship  systems  was  provided  in  order  to  familiarize  the  reader 
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with  existing  systems  or  in  other  terms,  familiarize  the  reader  with  what  has  been  done 
before.  The  description  of  the  evolution  of  four  major  elements,  mission  equipment 
electrical  power,  MDA  mission  personnel  berthing,  TTS  antenna  placement,  and  the 
communications  system  was  provided  to  give  the  reader  a  sense  of  the  major  design 
issues  confronting  the  conversion  project.  Three  of  the  major  design  efforts,  electrical 
power  system,  berthing,  and  placement  of  the  TTS  antennas  with  radomes  have  little  or 
nothing  to  do  with  interoperability.  Of  the  four  major  design  efforts  only  the 
communications  system  is  significant  to  interoperability. 

According  to  the  Defense  Science  Board,  the  major  reasons  for  using  a 
standardized  architecture  description,  such  as  DoDAF,  is  to  ensure  interoperable  and  cost 
effective  military  systems  (USD(A&T),  ASD(C3I),  J6,  1997).  To  paraphrase  the  DAU 
Glossary,  interoperability  for  the  Pacific  Tracker  system  is  its  ability  to  provide  data  and 
information  and  accept  the  same  from  the  Range  and  other  test  assets  and  to  use  the  data 
and  information  to  enable  them  to  operate  effectively  together.  The  Pacific  Tracker’s 
communication  system  is  an  integral  part  of  its  interoperability.  Since  DoDAF  grew  out 
of  the  1997  Command,  Control,  Communications,  Computers,  Intelligence,  Surveillance, 
and  Reconnaissance  (C4ISR)  Architecture  Framework  (DoDAF  Version  1.5  v  I),  one 
might  conclude  that  DoDAF  would  have  been  very  useful.  If  this  had  been  the  first  time 
a  SATCOM  system  was  developed  to  interface  with  a  test  range,  the  preceding 
conclusion  would  likely  be  valid.  For  the  Pacific  Tracker,  it  is  not  a  valid  conclusion 
because  it  has  been  done  before.  It  has  been  done  before  on  Pacific  Collector, 
KMRSiSI Worthy,  and  the  MLP.  While  the  communication  system  on  Pacific  Tracker  is 
more  complex  than  the  other  three,  it  is  not  much  more  complex.  With  the  two  sensors,  it 
is  more  of  a  question  of  bandwidth  than  complexity. 

In  order  for  the  Pacific  Tracker  system  to  be  interoperable  with  the  Ranges,  the 
two  sensors  have  to  be  interoperable  with  the  Ranges  as  well  as  the  communication 
system.  Here  again,  it  has  been  done  before.  The  TTS-2  is  already  interoperable,  it  is  an 
operating  system.  Its  twin,  TTS- 1 ,  is  already  operating  on  Pacific  Collector.  While  the 
XTR-I  has  yet  to  be  fielded,  it  “...is  based  on  the  modem  Radar  Open  Systems 
Architecture  originally  developed  for  the  suite  of  instmmentation  radars  at  the  Reagan 
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Test  Site”  (MIT  Annual  Report  2008).  Because  the  issues  associated  with 
interoperability  have  been  previously  resolved  and  the  other  major  parts  do  not  impact 
interoperability,  the  utility  of  DoDAF  to  the  Pacific  Tracker  system  was  limited. 

The  utility  of  DoDAF  seemed  to  be  more  associated  with  the  operational  views 
than  the  systems  views.  The  organizational  view,  OV-4,  and  the  process  view,  OV-5, 
proved  to  be  the  most  interesting.  They  provided  additional  insight  to  the  non-technical 
areas  of  the  program.  As  this  thesis  defined  the  Pacific  Tracker  conversion  effort, 
establishing  processes  for  mission  planning  and  pre-test  event  coordination  are  not  part  of 
the  conversion  effort.  The  design  of  the  processes  and  organizations  necessary  for 
successful  operation  of  the  Pacific  Tracker  are  candidates  for  further  research. 
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V.  SOME  IMPLICATIONS  FOR  OTHER  MDA  TEST  ASSET 
DEVELOPMENT  PROJECTS 


The  Beaver  State  conversion  project  has  been  successful  without  the  use  of 
DoDAF.  This  was  due  in  large  part  to  major  interoperability  issues  having  already  been 
resolved.  This  may  not  always  be  the  case.  Other  test  asset  development  projects  are 
likely  to  benefit  as  the  complexity  of  the  test  asset  interoperability  issues.  The  other 
implication  is  the  interoperability  of  organizations  and  processes  associated  with  BMDS 
flight  testing  should  also  be  considered. 

The  development  of  DoDAF  products  did  not  produce  significant  insights  in 
regards  to  the  four  major  elements,  mission  equipment  electrical  power,  MDA  mission 
personnel  berthing,  TTS  antenna  placement,  and  the  communications  system.  However, 
the  development  of  DoDAF  products  relative  to  organizations  and  processes  related  to 
the  project  did  provide  useful  insights.  The  products  OV-4  and  OV-5,  in  particular,  were 
useful.  These  products  illustrated  some  complications  with  management  of  the  project. 
While  outside  the  scope  of  this  thesis,  an  OV-5  depiction  of  the  process  which  provides 
data  collections  requirements  to  the  Pacific  Tracker  program,  revealed  several  process 
ambiguities  which  may  lead  to  confusion  in  the  future. 
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